W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2011

Re: [css3-fonts] font selection for Unicode Variation Selector

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>
Message-ID: <893918329.461155.1298864533727.JavaMail.root@cm-mail03.mozilla.org>
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

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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:10:22 UTC