bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7913: 23.2; Mac OS X Dual Spacing Fonts Fix (Patch supplied)


From: Jan Djärv
Subject: bug#7913: 23.2; Mac OS X Dual Spacing Fonts Fix (Patch supplied)
Date: Tue, 01 Feb 2011 08:49:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7



Emacs (v23.2 distro in my case) has a known problem with determining
pixel width of frames when using dual-space (Japanese) fonts.  It
arises because the maximum pixel width of characters in those fonts is
way bigger than (usually double the size of) the printable ASCII
characters.  Therefore, windows open twice as wide, and the
intelligent line wrapping (as in man or Mew, my favorite email reader)
gets the metrics wrong and forces the text to be wrapped to about one
third of the frame width.

Patches for X-Windows versions are known, and can be found on Ubuntu
mailing lists.  The same problem appears on NextSTEP, i.e., Mac OS
X/Cocoa version.  Below is the patch that solves the problem:

% ..................................................................

--- nsfont-old.m        2011-01-18 13:36:39.000000000 +0100
+++ nsfont.m    2011-01-18 13:36:17.000000000 +0100
@@ -885,9 +885,29 @@ nsfont_open (FRAME_PTR f, Lisp_Object fo
      font->ascent = lrint([sfont ascender]);
      font->descent = -lrint(floor([sfont descender]));
      font->min_width = ns_char_width(sfont, '|');
-    font->space_width = lrint (ns_char_width (sfont, ' '));
-    font->average_width = lrint (font_info->width);
-    font->max_width = lrint (font_info->max_bounds.width);
+    if([nsfont isFixedPitch]) {
+      /* This is a "dirty" fix to avoid problem with some (mostly
+        Japanese) fonts that use dual spacing. Unlike in the patches
+        to "ftfont.c" and "xftfont.c", in Cocoa we cannot rely on a
+        flag (FC_DUAL) to tell us if a fixed width font uses dual
+        spacing or not.
+
+        To avoid some problems with spaces (e.g. inside the vebatim
+        LaTeX environment when using AUCTeX), we measure the width of
+        a "regular" character, e.g. M (the size of em-space). */
+      font->space_width = lrint (ns_char_width (sfont, 'M'));
+      /* We assume it is the average width. */
+      font->average_width = font->space_width;
+      /* We also assume it is the maximal width.  This may possibly
+        cause some side effects, but I am not aware of any right
+        now. */
+      font->max_width = font->space_width;
+    } else {
+      /* This is the normal v23.2 code */
+      font->space_width = lrint (ns_char_width (sfont, ' '));
+      font->average_width = lrint (font_info->width);
+      font->max_width = lrint (font_info->max_bounds.width);
+    }
      font->height = lrint (font_info->height);
      font->underline_position = lrint (font_info->underpos);
      font->underline_thickness = lrint (font_info->underwidth);

Basically what you do is replace average width with the width of 'M'? If it is a fixed pitch font, max_width, average_width and space_width should all be the same so I don't understand why you substituted space for 'M'. I'm guessing it is the setting of max_width that fixes the problem?
Does this make your frames half as big as they where before?

Do you have a font I can use to see the problem?

        Jan D.


        Jan D.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]