[Top][All Lists]

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

Font back end font selection process

From: Adrian Robert
Subject: Font back end font selection process
Date: Sun, 7 Jun 2009 10:54:09 +0700

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.

reply via email to

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