Re: [css3-fonts] Font fallback for grapheme cluster and IVS

> A Japanese blog page[1] inspired me on a good clarification of the
> issue.
> 
> First, as John Daggett said before in this ML, there are two
> separate issues; one for grapheme cluster and another for IVS.
> 
> The former is if the UA should use code point for font fallback, or
> grapheme cluster. My vote is to use grapheme cluster, but I'd like
> to wait for John's investigations.

I don't think there's anything to vote for here, the question is how
best to do font selection for grapheme clusters that involve more than
a single codepoint.  This was discussed on the list back in February
and I think the description Eric Muller outlined makes
the most sense.

> IVS has yet another issue; IVS defines its fallback mechanism, and
> CSS3 Fonts defines its fallback mechanism too. The question is how
> these two fallback mechanisms should be combined to work together.

You're comparing apples and oranges here.  The IVS spec defines
codepoint fallback, it does not define *font* fallback.  The nature of
the IVS database adds a number of complications to this issue here, as
I noted back in February on the list [2].

> Here's an example. Author specified:
>   font-family: A B;
> and want to display "U+559D U+E0101" (U+E0101 is an IVS.)
> 
> Unicode allows "U+559D U+E0101" to fallback to "U+559D". CSS3 Fonts
> allows font A to fallback to font B, so here're possible
> combinations.
> 
> Option 1:
> 1. Search "U+559D U+E0101" in font A
> 2. Search "U+559D" in font A
> 3. Search "U+559D U+E0101" in font B
> 4. Search "U+559D" in font B
> 
> Option 2:
> 1. Search "U+559D U+E0101" in font A
> 2. Search "U+559D U+E0101" in font B
> 3. Search "U+559D" in font A
> 4. Search "U+559D" in font B
> 
> I think these two are reasonable options. The blog mentions that
> there's an implementation that behaves:
> 
> Option 3:
> 1. Search "U+559D U+E0101" in font A
> 2. Search "U+559D" in font A
> 3. Search "U+559D" in font B

The underlying article [3] is a really good example of the
difficulties surrounding IVS handling, thanks for pointing it out. The
article is in Japanese but there's an illustration of the possible
variations of U+908A that illustrates the problem. There are more
permuatations than the three listed above because it's not clear where
system font fallback occurs and because of the interrelationships
between selectors and the standard default glyph.

The IVS registration scheme allows overlapping registrations of the
same glyph (i.e. two variation selectors may actually refer to the
same underlying glyph) and the Hanyo-Denshi selectors appear to
duplicate many of the previously defined Adobe-Japan1 selectors. As I
pointed out back in February, over 90% of the variation selectors
among the Adobe-Japan1 selectors are the default glyph, so for those
selectors the "ideal" fallback will be Option 1, not Option 2, for
fonts lacking an IVS cmap.

In many cases, understanding these complex interrelationships will
lead to the most stylistic consistency, avoiding the ransom note
effects caused be switching between Gothic and Mincho faces along a
line of text.  Defining rules that *require* using a mixture of fonts
on a line when a single font would suffice and be correct is what we
must avoid here.  Play around with 'U+908A U+E0100' with the example
above for an indication of what I mean.

>From a spec point of view, what I don't like is that to construct the
ideal fallback given this situation is relatively complex and involves
mapping data that isn't currently publicly available (I've heard that
various folks have constructed mappings between the Hanyo-Denshi and
Adobe-Japan1 selector sets but it's hard to base a standard on that).
This is not a situation where option 1 or option 2 is universally better.

So for the CSS3 Fonts spec I think the best we can do is to define it
so that format-14 cmaps must be supported but that user agents are
allowed a certain amount of leeway in dealing with fonts that don't
support a given IVS selector.  As implementors, authors and font
designers work more with IVS selectors, hopefully a "best practice"
way will emerge and we can put that into a future version of the spec.

Regards,

John Daggett

[1] http://lists.w3.org/Archives/Public/www-style/2011Feb/0818.html
[2] http://lists.w3.org/Archives/Public/www-style/2011Feb/0799.html
[3] http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/

p.s. Hopefully there won't be more IVS selector registrations that overlap existing
ones but that may be wishful thinking.

Received on Friday, 27 May 2011 02:24:29 UTC