- From: John Daggett <jdaggett@mozilla.com>
- Date: Sun, 27 Feb 2011 23:25:05 -0800 (PST)
- To: Jonathan Kew <jonathan@jfkew.plus.com>
- Cc: Asmus Freytag <asmusf@ix.netcom.com>, www-style@w3.org, John Hudson <tiro@tiro.com>, public-i18n-cjk@w3.org, www-international@w3.org, Koji Ishii <kojiishi@gluesoft.co.jp>
Jonathan Kew wrote: > Rather than treating IVS sequences as a special case, though, I > wonder whether it would be better to specify that the font > matching algorithm should operate at the level of default > grapheme clusters, not individual characters (falling back to > individual-character matching only if no font is available that > supports the complete cluster). In general, it seems > undesirable for a font change to occur within a default > grapheme cluster (e.g. between a base character and an > associated diacritic); it would be better to render the entire > cluster using a font that supports all its components. I was actually thinking about this last week while revising the font matching description in the Editor's Draft of CSS3 Fonts. I agree this might be a good idea but I think the actual details are a bit devilish. My initial thought was for each font in the font list to initially match grapheme, then individual characters. But it seems to me there are some rather tricky issues involving when/whether to normalize, partial combinations etc. My proposal was along these lines: Given a grapheme, for each font in the fontlist: 1. Test for cmap support of base + all combiners, stop if match 2. If can be normalized to precomposed character, test cmap for precomposed character, stop if match 3. Match individual characters, fallback for unsupported characters I think you're proposing basically to fall through the entire fontlist for the first step. Not sure how exactly system fallback fits into what you're proposing. Regards, John Daggett
Received on Monday, 28 February 2011 07:27:42 UTC