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

Koji Ishii wrote:

> You have a font that supports Adobe-Japan1 IVS you want to use
> primary, but you also have a font that supports both
> Adobe-Japan1 IVS and Hanyo-Denshi IVS. Or you could want to use
> Palatino as a primary body font, but you have a font that has
> glyphs for Unicode Standard Variants[1].
> 
> You may then enter IVS/UVS though your Input Method Editor, or
> copy the text with IVS/UVS from your e-mail as a plain text.
> The glyphs will not show correctly until you select the span
> and apply different font.
> 
> Someday after that, you may want to change the font of the
> paragraph that includes IVS/UVS. Select the paragraph and apply
> the font to see that the glyphs changed to what you do not
> want.
> 
> These experiences feel me that it's like what I had in '80 or
> early '90 before Unicode; the code point were shared among the
> locales, and therefore you have to apply Latin font to Latin
> text and East Asian font to East Asian text by yourself. If you
> apply incorrect fonts, glyphs will be broken. Unicode came in
> to rescue, where code point determines the glyph
> (non-formatting information) and font determines styles.
> 
> I think IVS/UVS not being able to display properly without
> applying the appropriate font at the top of the font list makes
> the users of IVS/UVS back to those days. As I said, if the
> feature was intended to work that way, that's only a font
> feature. It was done in Unicode because people wanted to work
> without styling information.
> 
> The problem for me to show a use case is that the technology is
> still new, so while the font section above is an actual use
> case, "enter IVS/UVS through IME" hasn't happened yet. But I
> think it will happen before CSS3 fonts go REC. That's my guess
> or hope, not an real use case we have today though.

I do think variation selector support is important to require in
CSS.  I've added this requirement to the latest Editor's Draft.

However, what you're arguing for here is how variation selectors
are handled as part of *system* font fallback (e.g. you specify
'Arial' for a text run containing Japanese).  Font matching in
CSS is specified for author-specified fontlists but it is
explicitly *not* specified for system font fallback beyond the
use of a missing character symbol if no glyph is found for a
given character.

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.

Regards,

John Daggett

Received on Friday, 25 February 2011 06:26:25 UTC