[Top][All Lists]

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

bug#3174: NS font selection still broken

From: Kenichi Handa
Subject: bug#3174: NS font selection still broken
Date: Mon, 02 Nov 2009 13:06:51 +0900

In article <address@hidden>, Adrian Robert <address@hidden> writes:

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

For selecting a font that supports a specific script, xft
backend utilizes script-representative-chars which maps a
script to a few representative characters of the script.
>From a set of fonts found that way, the code in fontset.c
chooses the best font that actually supports the target

Kenichi Handa

reply via email to

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