[Top][All Lists]

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

bug#3174: NS font selection still broken

From: Adrian Robert
Subject: bug#3174: NS font selection still broken
Date: Thu, 29 Oct 2009 14:43:25 -0400


For debugging it will be more useful to compare with another port on Emacs-23 (e.g., X11) than Carbon Emacs 22, as character rendering and font selection was changed completely.

For differences from w32 or x11 that show up on Emacs 23, font selection is handled through ns_findfonts() in nsfont.m. The rewrite of a few months ago brought this mostly in line with other ports, but some crucial differences may still remain (though I'm not sure what they are). I'm afraid it will take a fairly significant effort at turning on tracing in that file (NSFONT_TRACE at the top), and working through the logic of what font.c is doing and what nsfont.m is doing, for the characters in question. I can't think of any shortcuts, and I have to admit these mathematical symbol ranges have long been a problem eluding my efforts, though I believe the rewrite lessened the number of erroneously-handled characters.

The actual "bugs" could be either in nsfont.m or font.c -- sometimes in the past nsfont's different implementation sometimes revealed problems in font.c that did not affect other ports. (Of course the nsfont.m impl should continue to be normalized to the other ports so such bugs can remain mercifully hidden.)

I'm not sure #3588 is related, as the 'italic' property is a confound there.


On Oct 29, 2009, at 2:18 PM, David Reitter wrote:

Adrian, readers of bugs 3174 and 3588,

There are still some bad issues with the font selection in the NS port.

For example, take the following unicode characters:

[∃]  2203  THERE EXISTS
[∈]  2208  ELEMENT OF

They are rendered perfectly in the Carbon port (at least in Aquamacs).

In NS, it uses Symbol for 2203, even though the glyph is available in the default font (like Monaco or Lucida Grande).
As a consequence, the symbol looks very small and is unreadable.

As for 2203, it also uses Symbol, even though Symbol doesn't even have the glyph.

This is on Snow Leopard.

I'm wondering if this is this the same bug as #3588. I would write to emacs-devel to ask for help, but I don't even know what exactly the problem is in the underlying code, and whether this is NS specific (I guess so)... I can happily file another bug report so we've got something to ignore :)

Let me know what if I can help.

- David

reply via email to

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