gnustep-dev
[Top][All Lists]
Advanced

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

Re: ANN: Emacs on GNUstep / OS X 8.0-rc1


From: Adrian Robert
Subject: Re: ANN: Emacs on GNUstep / OS X 8.0-rc1
Date: Wed, 09 Mar 2005 11:08:17 -0500

On Mar 8, 2005, at 10:15 AM, M. Uli Kusterer wrote:

At 16:42 Uhr -0500 07.03.2005, Adrian Robert wrote:
http://emacs-on-aqua.sf.net/

Status respecting backends on GNUstep is unchanged: works on Xlib, has
rendering anomalies under Art.  Specifically, menus are rendered blank
when they change, and the letter 'f' is rendered in proportional spacing (from NSString -drawAtPoint:withAttributes:) in all fonts tried (in some
cases the character after the 'f' must be 'i' or another 'f').
"defaults write Emacs GSBackend libgnustep-xlib" is necessary.
 Not sure whether you already know the source of the "f" problem and 
simplified the explanation, or whether you don't know where this comes 
from, but this looks to me like ligatures are turned on where they 
shouldn't. Ligatures are a typographical fanciness for representing 
certain character pairs with a single character that looks like an 
amalgamation of the two. Often done for fi, fl and a few others.
 I think there should be a way to turn of ligatures, but you may have 
to use the Cocoa text system directly instead of using NSString's 
drawAtPoint:.
Yes, the rendering issue did have to do with ligature, but the fault is 
not in Art, but in GUI.  Art just reveals the issue because it 
implements ligature whereas Xlib does not.
The problem is in [GSLayoutManager -_run_cache_attributes], where it 
currently sets a glyph run's 'ligature' attribute by default to '1'.  
Either it should set this to '0' if the font is monospaced, or some 
lower level should ignore ligature=1 for fixed fonts.
This raises the question of how to detect monospaced fonts.. if you ask 
[NSFont -isFixedPitch], you usually get NO even for fonts that are 
"supposed to be" monospaced.  This is a known issue even on OS X, and 
relates to the fact that most fonts seem to have a few characters 
somewhere with a different width.  (This is presumably why, e.g., not 
all fixed-width fonts on the system show up under that category in the 
OS X font panel.)
One quick-and-dirty hack found on the web is to check if 'i' and 'm' in 
the font have the same width.  On Art, this test passes for FreeMono, 
which does indeed render as a fixed-width font, and fails for 
BitstreamVeraSansMono-Roman.  This is correct, as the latter seems not 
to be a fixed-width font.. see attached screenshot, in which the top 
row is a "natural" rendering (in TextEdit), while the bottom is a 
rendering in emacs when spacing is forced to be fixed (by moving the 
cursor over the row).  Paradoxically, in the natural rendering we see 
'm' is actually rendered _skinnier_ than 'i'.

PNG image


Although correct in this case, the 'i'/'m' hack seems sloppy and also might be inefficient and/or inaccurate. Other recommendations are welcome.
Also, can anyone recommend a good fixed-width font usable under Art?  
FreeMono looks greyed-out on my system...
Thanks.

reply via email to

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