bug#3174: NS font selection still broken

[Kenichi Handa]

In article <2FBE059F-5AE1-4DB7-A325-80F49ACF2490@gmail.com>, Adrian Robert 
<adrian.b.robert@gmail.com> 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
character.

---
Kenichi Handa
handa@m17n.org