- From: John Daggett <jdaggett@mozilla.com>
- Date: Sun, 27 Feb 2011 19:42:13 -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: >>> If the user has fonts that can show the variation, I would tend >>> to agree with Koji that it is a very unfriendly design if the >>> user must always be aware of the presence of variation >>> sequences in the text when deciding on the font selection. Such >>> a design also performs poorly where authorship of the text and >>> authorship of the style sheet are unrelated and / or are >>> performed at different times. >> >> CSS font matching does *not* require a system font fallback >> procedure that searches all fonts for a given character. Most >> user agents support some form of default font mechanism which >> allows a user to specify the font to use in the case of system >> font fallback for a given language or character range. By >> specifying fonts with full IVS support, users can achieve the >> results you're looking for. > > That does not help the case where the primary font the author > wants to use - the first name in the 'font-family' property - > supports the base Unicode character involved but does not support > the specific variation selector. AIUI, Koji-san would like 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). The flip side of this is that given the same environment, for the style rule below your proposal will *always* result in a change of font, even when the author doesn't want this: font-family: 'My Favorite Font'; As with anything, the devil is in the details here. Of the 13,276 codepoints with registered variation selectors in the IVD Adobe-Japan1 collection, only 1,206 have more than one selector [1]. So always falling back to match a given font with a format 14 cmap misses the fact that 91% of the variation selectors are simply the default glyph (i.e. what you would get if falling back to the base character)! The Hanyo-Denshi collection appears only to define selectors for cases where at least one alternate variation exists. Of the 4,195 selectors defined, 1,918 represent the default glyph. One could reasonably argue that authors would only use variation selectors to indicate the non-default glyph but that's making a rather large assumption about the authoring environment. For fonts in fontlists that don't support a given variation selector, neither of the fallback choices is going to be ideal in all cases. If fallback occurs to the base character, an author preserves a consistent look in the typeface but loses the desired variation in the non-default case. If fallback occurs to the first font that contains the desired variation, an author preserves the variation but potentially shows something visually jarring due to the change in font. Given that some ISV variations are rather subtle, a change in font could easily end up in a result that wasn't stylistically coherent at all. An analogue to this would be a font fallback bug that existed in Firefox at one point, on OSX the font fallback algorithm was such that Zapfino was chosen as the font used to represent the presentational ligature for 'ff', U+FB00. Instead of the subtle variation the author was seeking the result was wildly incongruent text runs because of the calligraphic styling of Zapfino glyphs. Regards, John Daggett [1] http://www.unicode.org/ivd/data/2010-11-14/IVD_Sequences.txt
Received on Monday, 28 February 2011 03:45:34 UTC