- From: Asmus Freytag <asmusf@ix.netcom.com>
- Date: Sat, 26 Feb 2011 12:00:48 -0800
- To: Jonathan Kew <jonathan@jfkew.plus.com>
- CC: John Daggett <jdaggett@mozilla.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>
On 2/25/2011 1:07 AM, Jonathan Kew wrote: > Koji-san would like [users] to be able to say something like > font-family: 'My Favorite Font', 'My Special IVS Font'; > > where 'My Special IVS Font' provides glyphs for IVS sequences that are not supported in 'My Favorite Font', but he does not want to switch the entire text to the 'Special IVS' font (perhaps it doesn't even support all the same standard Unicode characters as the 'Favorite' one). There are multiple levels of this. The scenario extends: font-family: 'My Favorite Font', 'Some generic font', 'Special IVS Font', 'Generic IVS Font'; > 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 This is a reasonable approach. For IVS the whole sequence would be in one font (because the selector characters don't have glyphs), and for combining marks, in most cases it makes no sense to apply a mark from one font to a base character from another. I can think of some weird exceptions, but the results, even if implementations supported that, would likely be rather haphazard. Layout engines usually divide things into font runs to begin with and then apply layout, making grapheme clusters that have a font run boundary not very useful or workable. > (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. Correct. On 2/26/2011 11:11 AM, John Hudson wrote: > > > Recently, there has been ISO movement on standardising a composite > font format, i.e. a mechanism to define virtual fonts from collections > of individual fonts, specifying which component fonts should be used > for which characters. There are limits to the typographic > sophistication of such an approach that will require fairly careful > use of the mechanism (layout features will not apply across component > font boundaries). But it seems to me that something like this could > provide a solution to the problems you have raised. In this context, the way a CSS statement like font-family: 'My Favorite Font', 'Some generic font', 'Special IVS Font', 'Generic IVS Font'; ought to work is that it sets up a composite font selection on the fly. Each grapheme cluster would then be rendered at the first font encountered that is able to render it. I've used my own composite font mechanism for decades as part of the process of printing the Unicode code charts. For that application it's particularly nice to be able to pretend that one has a single "Unicode font". From that experience I know that performance issues can be tackled successfully (our composite fonts contain hundreds of entries). A./
Received on Saturday, 26 February 2011 20:01:54 UTC