all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Font back end font selection process
@ 2009-06-07  3:54 Adrian Robert
  2009-06-07  5:59 ` Stephen J. Turnbull
  2009-06-08  2:49 ` Kenichi Handa
  0 siblings, 2 replies; 5+ messages in thread
From: Adrian Robert @ 2009-06-07  3:54 UTC (permalink / raw)
  To: Emacs-Devel devel

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.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-06-10 11:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-07  3:54 Font back end font selection process Adrian Robert
2009-06-07  5:59 ` Stephen J. Turnbull
2009-06-08  2:49 ` Kenichi Handa
2009-06-10  7:27   ` Adrian Robert
2009-06-10 11:04     ` Kenichi Handa

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.