Font back end font selection process

[Adrian Robert]

I am working on updating the NS font driver to work with script and  
friends so that correct nonASCII fonts can be chosen using the  
default fontset skeleton mechanism.  The back end seems to use these  
methods to request a font from the list() method:

- registry in the font spec proper
- :script property in "extra" properties
- :lang property in "extra"
- part of the :otf property bundle in "extra"

I haven't found a way to respond to the first type of query using  
Cocoa APIs yet.  The others that get requested, and the order, seems  
to depend on the language in question.  In particular, for some  
languages like Thai, only OTF requests ever seem to get made.  It  
seems like this class might be the scripts requiring compositional  
rendering, but why, since emacs used to be able to handle  
compositional rendering without making use of any OTF-specific  
properties provided by a font driver?

Also, often I have noticed that when given a Chinese text file  
(encoded in UTF-8), the only request that comes through is :lang=ja.   
How should the font driver know to return a kanji font instead of  
hiragana / katakana?.  Wouldn't it would be better to  
request :script=han, adding :lang=ja or :lang=zh only if emacs has  
some knowledge that the file IS actually in one of these languages?   
The file encoding might be one piece of information to take into  
account, but when it is UTF-8 it would need to run some kind of  
lexical analysis, or query the user.

I also noticed that if no entities are returned from a list() request  
with a family and a script specified, it next makes a list() request  
with no family specified.  Instead of this it would be good to  
request a match() with the family still specified, as this gives the  
driver the opportunity to find a font that "looks like" the family  
(e.g. presence of serifs, etc.), instead of just a random font  
covering the needed characters.  Indeed, I have not noticed match()  
being called at all when searching for a font for a script -- instead  
the back end just goes with the ascii font (and rendering boxes)  
before ever making such a request.