* Problem with chinese gbk fonts on w32 @ 2005-08-01 2:31 Sun Yijiang 2005-08-01 7:08 ` Jason Rumney 0 siblings, 1 reply; 6+ messages in thread From: Sun Yijiang @ 2005-08-01 2:31 UTC (permalink / raw) [-- Attachment #1.1: Type: text/plain, Size: 736 bytes --] The first screenshot (w32bdf-bad.png) is from Emacs on w32 with "src/w32bdf.c" revision 1.21 and later, and the second (w32bdf-nice.png) is the same with "src/w32bdf.c" revision 1.20. The changelog says (from 1.20 to 1.21): (w32_load_bdf_font): Set fontp->average_width and fontp->space_width to FONT_WIDTH so they are valid. I think this change is probably not fully tested. When I use the mule-gbk package and set font for chinese characters, they look so wide, but when I use "emacs -q" they look nice, make no difference with previous CVS Emacs. I roll back the src/w32bdf.c to older version, and everything is OK. I think the change of w32bdf.c should be reviewed, since this is really a bug. Sun Yijiang [-- Attachment #1.2: Type: text/html, Size: 798 bytes --] [-- Attachment #2: w32bdf-bad.png --] [-- Type: image/png, Size: 10181 bytes --] [-- Attachment #3: w32bdf-nice.png --] [-- Type: image/png, Size: 8688 bytes --] [-- Attachment #4: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with chinese gbk fonts on w32 2005-08-01 2:31 Problem with chinese gbk fonts on w32 Sun Yijiang @ 2005-08-01 7:08 ` Jason Rumney 2005-08-01 8:38 ` Sun Yijiang 0 siblings, 1 reply; 6+ messages in thread From: Jason Rumney @ 2005-08-01 7:08 UTC (permalink / raw) Cc: emacs-devel Sun Yijiang <sunyijiang@gmail.com> writes: > I think this change is probably not fully tested. When I use the > mule-gbk package and set font for chinese characters, they look so > wide, but when I use "emacs -q" they look nice, make no difference > with previous CVS Emacs. I roll back the src/w32bdf.c to older > version, and everything is OK. I think the change of w32bdf.c should > be reviewed, since this is really a bug. You seem to be saying that you only see the "bug" when you load mule-gbk, which is not part of Emacs. What does mule-gbk do? Does it perhaps try to work around the previous bug by doubling the width of Chinese characters? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with chinese gbk fonts on w32 2005-08-01 7:08 ` Jason Rumney @ 2005-08-01 8:38 ` Sun Yijiang 2005-09-06 7:43 ` Sun Yijiang 0 siblings, 1 reply; 6+ messages in thread From: Sun Yijiang @ 2005-08-01 8:38 UTC (permalink / raw) Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --] Sorry, I've reviewed my .emacs and found where the problem is. The problem is NOT mule-gbk, it's "create-fontset-from-fontset-spec". Following setting results in double-width Chinese characters: (create-fontset-from-fontset-spec "-*-bitstream vera sans mono-normal-r-*-*-14-*-*-*-c-*-fontset-gbk, chinese-gb2312:-*-simsun-normal-r-normal-*-16-*-*-p-*-gb2312*-*, chinese-cns11643-5:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*, chinese-cns11643-6:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*, chinese-cns11643-7:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*" t) I think the problem is that I set different fonts for each char set. If I comment out this setting and still use mule-gbk, Chinese characters looks OK. If I use this setting, the Chinese characters looks double-width, either with or without mule-gbk. This setting works for previous CVS Emacs builds and seems to become "bad" recently. I remember this problem first appeared with a check in of w32bdf.c early this year. The problem can be resolved by rolling back w32bdf.c to revision 1.20 at that time. But now even this rolling back does not work, maybe other changes affects this problem. 2005/8/1, Jason Rumney <jasonr@gnu.org>: > > Sun Yijiang <sunyijiang@gmail.com> writes: > > > I think this change is probably not fully tested. When I use the > > mule-gbk package and set font for chinese characters, they look so > > wide, but when I use "emacs -q" they look nice, make no difference > > with previous CVS Emacs. I roll back the src/w32bdf.c to older > > version, and everything is OK. I think the change of w32bdf.c should > > be reviewed, since this is really a bug. > > You seem to be saying that you only see the "bug" when you load > mule-gbk, which is not part of Emacs. What does mule-gbk do? Does it > perhaps try to work around the previous bug by doubling the width of > Chinese characters? > > [-- Attachment #1.2: Type: text/html, Size: 2363 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with chinese gbk fonts on w32 2005-08-01 8:38 ` Sun Yijiang @ 2005-09-06 7:43 ` Sun Yijiang 2005-09-06 8:00 ` Jason Rumney 0 siblings, 1 reply; 6+ messages in thread From: Sun Yijiang @ 2005-09-06 7:43 UTC (permalink / raw) Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 2822 bytes --] I think I've found the problem, here is the patch of w32fns.c (against revision 1.256). I don't know the detail, but this patch works. --------------------------------------8<-------------------------------------- --- w32fns.c 2005-08-08 09:45:47.000000000 +0800 +++ w32fns-fix.c 2005-09-06 15:32:01.275812264 +0800 @@ -4545,7 +4545,7 @@ /* Fill out details in lf according to the font that was actually loaded. */ lf.lfHeight = font->tm.tmInternalLeading - font->tm.tmHeight; - lf.lfWidth = font->tm.tmMaxCharWidth; + lf.lfWidth = font->tm.tmAveCharWidth; lf.lfWeight = font->tm.tmWeight; lf.lfItalic = font->tm.tmItalic; lf.lfCharSet = font->tm.tmCharSet; --------------------------------------8<-------------------------------------- 2005/8/1, Sun Yijiang <sunyijiang@gmail.com>: > > Sorry, I've reviewed my .emacs and found where the problem is. The > problem is NOT mule-gbk, it's "create-fontset-from-fontset-spec". > Following setting results in double-width Chinese characters: > > (create-fontset-from-fontset-spec > "-*-bitstream vera sans mono-normal-r-*-*-14-*-*-*-c-*-fontset-gbk, > chinese-gb2312:-*-simsun-normal-r-normal-*-16-*-*-p-*-gb2312*-*, > chinese-cns11643-5:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*, > chinese-cns11643-6:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*, > chinese-cns11643-7:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*" t) > > I think the problem is that I set different fonts for each char set. If > I comment out this setting and still use mule-gbk, Chinese characters > looks OK. If I use this setting, the Chinese characters looks > double-width, either with or without mule-gbk. This setting works for > previous CVS Emacs builds and seems to become "bad" recently. > > I remember this problem first appeared with a check in of w32bdf.c > early this year. The problem can be resolved by rolling back w32bdf.c > to revision 1.20 at that time. But now even this rolling back does not > work, maybe other changes affects this problem. > > > 2005/8/1, Jason Rumney <jasonr@gnu.org>: > > > > Sun Yijiang <sunyijiang@gmail.com> writes: > > > > > I think this change is probably not fully tested. When I use the > > > mule-gbk package and set font for chinese characters, they look so > > > wide, but when I use "emacs -q" they look nice, make no difference > > > with previous CVS Emacs. I roll back the src/w32bdf.c to older > > > version, and everything is OK. I think the change of w32bdf.c should > > > be reviewed, since this is really a bug. > > > > You seem to be saying that you only see the "bug" when you load > > mule-gbk, which is not part of Emacs. What does mule-gbk do? Does it > > perhaps try to work around the previous bug by doubling the width of > > Chinese characters? > > > > > [-- Attachment #1.2: Type: text/html, Size: 4147 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with chinese gbk fonts on w32 2005-09-06 7:43 ` Sun Yijiang @ 2005-09-06 8:00 ` Jason Rumney 2005-09-06 8:13 ` Sun Yijiang 0 siblings, 1 reply; 6+ messages in thread From: Jason Rumney @ 2005-09-06 8:00 UTC (permalink / raw) Cc: emacs-devel Sun Yijiang wrote: > I think I've found the problem, here is the patch of w32fns.c (against > revision 1.256). I don't know the detail, but this patch works. > > --------------------------------------8<-------------------------------------- > --- w32fns.c 2005-08-08 09:45:47.000000000 +0800 > +++ w32fns-fix.c 2005-09-06 15:32:01.275812264 +0800 > @@ -4545,7 +4545,7 @@ > /* Fill out details in lf according to the font that was > actually loaded. */ > lf.lfHeight = font->tm.tmInternalLeading - font->tm.tmHeight; > - lf.lfWidth = font->tm.tmMaxCharWidth; > + lf.lfWidth = font->tm.tmAveCharWidth; > lf.lfWeight = font->tm.tmWeight; > lf.lfItalic = font->tm.tmItalic; > lf.lfCharSet = font->tm.tmCharSet; > --------------------------------------8<-------------------------------------- How can this work? The problem you reported was for BDF fonts used to display the GBK character sets. The fix above affects only Windows system fonts. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with chinese gbk fonts on w32 2005-09-06 8:00 ` Jason Rumney @ 2005-09-06 8:13 ` Sun Yijiang 0 siblings, 0 replies; 6+ messages in thread From: Sun Yijiang @ 2005-09-06 8:13 UTC (permalink / raw) Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1442 bytes --] I think I did not describe the problem properly. The problem is: 1) Only on W32 platform. 2) Has nothing to do with GBK. The problem arises together with create-fontset-from-fontset-spec, no matter I use GBK or GB2312. The patch works indeed. In fact, "font->tm.tmMaxCharWidth" is double of "font->tm.tmAveCharWidth", I think that's where the problem is. 2005/9/6, Jason Rumney <jasonr@gnu.org>: > > Sun Yijiang wrote: > > > I think I've found the problem, here is the patch of w32fns.c (against > > revision 1.256). I don't know the detail, but this patch works. > > > > > --------------------------------------8<-------------------------------------- > > --- w32fns.c 2005-08-08 09:45:47.000000000 +0800 > > +++ w32fns-fix.c 2005-09-06 15:32:01.275812264 +0800 > > @@ -4545,7 +4545,7 @@ > > /* Fill out details in lf according to the font that was > > actually loaded. */ > > lf.lfHeight = font->tm.tmInternalLeading - font->tm.tmHeight; > > - lf.lfWidth = font->tm.tmMaxCharWidth; > > + lf.lfWidth = font->tm.tmAveCharWidth; > > lf.lfWeight = font->tm.tmWeight; > > lf.lfItalic = font->tm.tmItalic; > > lf.lfCharSet = font->tm.tmCharSet; > > > --------------------------------------8<-------------------------------------- > > How can this work? > > The problem you reported was for BDF fonts used to display the GBK > character sets. > The fix above affects only Windows system fonts. > > [-- Attachment #1.2: Type: text/html, Size: 2306 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-09-06 8:13 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-08-01 2:31 Problem with chinese gbk fonts on w32 Sun Yijiang 2005-08-01 7:08 ` Jason Rumney 2005-08-01 8:38 ` Sun Yijiang 2005-09-06 7:43 ` Sun Yijiang 2005-09-06 8:00 ` Jason Rumney 2005-09-06 8:13 ` Sun Yijiang
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.