|
From: | Adrian Robert |
Subject: | bug#3174: NS font selection still broken |
Date: | Fri, 30 Oct 2009 10:51:45 -0400 |
I've been looking at the trace from nsfont and, more importantly, ` (reverse font-log)' from font.c.To display [“] 201C LEFT DOUBLE QUOTATION MARK, we get the log below (after adding a few items to log).At first (top of list), it tries to find "Apple Lucida Grande" and "Lucida Grande" with a particular "registry" and for the symbol script. This fails, because the `val' variable in font_list_entities ends up being Qnil.
This is as expected. The first query asks for fonts with family=Lucida Grande, that cover script=symbol. The way the second criterion is handled is the issue. ns_findfonts() has no idea whether the font is being requested just for some particular character or for rendering the script in general, so it tries to deliver a font that has "good coverage" of the requested script. This is handled by ns_get_covering_families() for the script, which looks at the whole set of characters provided by the font and returns those that cover a certain percentage of the characters in the unicode range for the script.
I don't see what other behavior would be reasonable here.Perhaps the 90% criterion (nsfont.m line 507) could be lowered; this might lead to other problems though -- I did experiment with this when setting it. The best thing at this point might be to do a similar trace against X11 or w32 and see where things differ. Of course, the available fonts will be different, so it is impossible to duplicate the conditions.
[Prev in Thread] | Current Thread | [Next in Thread] |