W3C home > Mailing lists > Public > www-style@w3.org > February 2011

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

From: Jonathan Kew <jonathan@jfkew.plus.com>
Date: Fri, 25 Feb 2011 09:07:48 +0000
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: <C96CD340-88EC-4D4B-A4DF-C86D553EE7F3@jfkew.plus.com>
To: John Daggett <jdaggett@mozilla.com>
On 25 Feb 2011, at 05:16, John Daggett wrote:

> Asmus Freytag 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).

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.

Received on Friday, 25 February 2011 09:08:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC