GNU bug report logs - #7913
23.2; Mac OS X Dual Spacing Fonts Fix (Patch supplied)

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Dragan Ivanovic <idragan <at> clip.dia.fi.upm.es>
Cc: 7913 <at> debbugs.gnu.org
Subject: bug#7913: 23.2; Mac OS X Dual Spacing Fonts Fix (Patch supplied)
Date: Tue, 01 Feb 2011 08:49:55 +0100

>
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.