|
From: | Adrian Robert |
Subject: | Font back end font selection process |
Date: | Sun, 7 Jun 2009 10:54:09 +0700 |
- 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.
[Prev in Thread] | Current Thread | [Next in Thread] |