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

Thank you Asmus for your support.

> If applying a style sheet to a text "breaks" the IVS,
> then this will create pressure to encode more of them
> as first class Unicode characters.

That's exactly what is being discussed. We consider them as separate glyphs, but if those glyphs cannot be displayed  by font fallback, we might want those glyphs as first class Unicode characters. That makes collation more difficult though.

And thank you Jonathan for writing down what I was trying to write in smarter English, that is really helpful.

I think John and I are getting closer, thank you John for the efforts, but I still see one thing we see differently.

> All of these issues will go away when default fonts supporting
> variation selectors are available.  Until then authors will need
> to specify or provide fonts for their content that requires
> specific glyphs.

I don't think this will happen ever. When Unicode was introduced in 90's, there were similar discussions. Unicode has all characters coded uniquely, so why would we ever want font fallback? Every font can support every glyph defined in Unicode, so we won't need such system.

After more than a decade, we know it never happened. There were some tries, like Arial Unicode, to create a font with every possible glyph. But it never be successful one because no single designer can be professional for every glyph all over the world, and two, web designers want their freedom for their favorite font choice. This is why we have font fallback in operating systems and in CSS today.

Adobe fonts do not support Hanyo-Denshi IVS today, but designers may want to use it as a primary font. Hiragino doesn't support neither IVS today, but designers may want to use it as a primary font. None of them support math and Mongolian variants.

I understand this is a very fundamental part, requires implementations to change their code of where performance is very keen, so I agree that the decision must be made very carefully.

But I don't think this issue can be resolved otherwise.


Regards,
Koji

-----Original Message-----
From: Jonathan Kew [mailto:jonathan@jfkew.plus.com] 
Sent: Friday, February 25, 2011 6:08 PM
To: John Daggett
Cc: Asmus Freytag; www-style@w3.org; John Hudson; public-i18n-cjk@w3.org; www-international@w3.org; Koji Ishii
Subject: Re: [css3-fonts] font selection for Unicode Variation Selector

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.

JK

Received on Saturday, 26 February 2011 15:28:48 UTC