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

Koji Ishii wrote:

> > The question is not difficulty, I don't think it's the right
> > behavior to require font fallback for UVS selectors.
> > It doesn't make sense to me the way the Unicode spec is
> > written, it doesn't make sense from given the way other
> > font variant features work and it doesn't make sense to
> > me from a performance perspective.
> 
> First, there are two perspective; "should", and "technically
> feasible", and I understand both are important. What you
> mentioned first is about "should", and performance etc. are the
> later. I would like to focus on "should" first, because you
> mentioned you don't think it's the right behavior. If we could
> agree on we "should", we could then discuss if it's feasible, or
> if there were any compromises to make it. If we agree on we
> "should NOT", then the discussion is over.

Again, I think you need to show a strong use case for supporting
UVS in font fallback.  What you're proposing effectively changes
font fallback from a simple single-pass procedure ("what font
supports character x?") to a two-pass procedure ("what font
supports character x + selector? if not found, what font supports
character x?").  It significantly complicates
character-by-character handling.  We should not be adding
complicated character-level handling unless there is a really
strong reason to do so.

In general, the philosophy behind the CSS3 Fonts spec is that
instead of relying on the uncertain results of font fallback,
authors can now use the @font-face mechanism to supply fonts that
meet the requirements of their content.  Font fallback for
variation selectors inevitably means the use of a mixture of
fonts across a text run, a result that's rarely ideal.  If an
author requires a given variation they should supply a font
containing it rather than relying on font fallback handling to
magically conjure up the "right" representation for a text run.

In this case "should" and "technically feasible" are not
independent issues, the question is whether the benefits of using
a given approach produces results that justify the complexity and
implementation cost. 

> He also raised another interesting question; if font B has "a"
> and Umlaut[3] while font A has only "a", and source text is
>   U+0061 LATIN SMALL LETTER A
>   U+0308 COMBINING DIAERESIS
> Would CSS render the glyph using font A or B? If it uses font A,
> the Umlaut will not be rendered.
> 
> He suggested that UVS is closer to the combining marks rather
> than OpenType font variant features.

The use of combining diacritics is completely different than the
use of variation sequences. An 'a' character with an umlaut is a
different character than an 'a' while a variation sequence
specifies a representation of a given character.  The mechanism
for handling combining diacritics is also different, in this case
most implementations would normalize the text to the codepoint
for a-umlaut *before* matching fonts.  Note that's not specified
in CSS, that's simply the way most text engines function.  Fonts
treat combining marks as separate codepoints which can be matched
independently (albiet with possibly undesirable results).  For
example:

  U+1F4A9 PILE OF POO
  U+0308  COMBINING DIAERESIS

Given a font that defines both these characters, this will render
as a pile of poo with an umlaut, even though there is no
normalized form for this. This will even render if the characters
come from different fonts, although the placement of the umlaut
may not be ideally placed over the poo. This is very different
from the way variation sequences work.

Regards,

John Daggett

Received on Tuesday, 22 February 2011 03:04:25 UTC