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

Koji Ishii wrote:

> >> 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.
> 
> I'm glad to hear that you agreed with Eric Muller's message[1],
> I agree with that too.

Fine, but the treatment of grapheme clusters in the font fallback
process is orthogonal to how IVS is handled.  The two should not
be conflated which you seem to want to do.

> >> 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].
> 
> I'm sorry that my wording was incomplete and misleading. You're
> right that the two are different things, but what I wanted to
> say here was that there's no clear agreement where the IVS
> codepoint fallback should fit into the logic Eric described[1].

Again, IVS doesn't fit in that logic.  The special nature of the
IVS means the solution will be more complex than the handling of
grapheme clusters.

> > 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.
> 
> I agree with you here. But you could also find that over 55% of
> the variation selectors among the Hanyo-Denshi selectors are
> not the default glyph today, and such Hanyo-Denshi selectors is
> going to increase to over 70% by the end of FY2011. I hope you
> understand that the situation is gradually changing and
> improving after the initial Adobe-Japan1 release.

No, it's not improving, it's bifurcating for no good reason and
that's the source of these complications.  For the *same* glyph,
authors now have to choose between two different variation
selectors.  And it doesn't help when newer fonts only support one
of these schemes (e.g. the beta version of IPAmjMincho only
supports Hanyo-Denshi selectors and ignores the Adobe-Japan1
selectors that map to identical glyphs).  It feels like we're
back to the 80's when every vendor had to have their very own
encoding scheme.

> Since today's situation splits, i.e., option 1 for Adobe-Japan1
> and option 2 for Hanyo-Denshi, if you believe that it's too
> early to spec it out, I have to agree to postpone it. But
> logically speaking, there's no way to add more default glyphs,
> so all glyphs being added to Adobe-Japan1/Hanyo-Denshi are new
> glyphs. It's going to favor option 2 more as time goes. I hope
> you understand this.

As I said in the last message, the situation is more complicated
than simply choosing between option 1 and 2.  The "ideal"
solution from a stylistic standpoint will unfortunately be more
complex and how to reduce that complexity needs to be worked out.

> It looks like you agree that option 3 is not a good way to
> handle IVS, that's a great news to me.

That's not an option, that's just a bug. ;)

Cheers,

John Daggett

Received on Saturday, 28 May 2011 22:15:07 UTC