- From: John Daggett <jdaggett@mozilla.com>
- Date: Thu, 12 Sep 2013 20:59:31 -0700 (PDT)
- To: Richard Ishida <ishida@w3.org>
- Cc: W3C Style <www-style@w3.org>, www International <www-international@w3.org>
Richard Ishida wrote: > 5.3. Cluster matching > http://www.w3.org/TR/2013/WD-css-fonts-3-20130711/#cluster-matching > > In the numbered list, what should follow if 1b holds true? Um, you select that font and great joy ensues? ;) That's the goal of both standard font matching and the font matching for clusters. Steps (2) and (3) are prefaced with "if no font was found..." so I don't see any ambiguity if that's what you're thinking there's something ambiguous here. > "If a sequence of multiple codepoints is canonically equivalent to a > single character and the font supports that character, select this font > for the sequence." > > Is this implying (though not stating, note), that the text should be > normalized so that the glyph for the canonically equivalent character > can be used? (I'm not sure that's a good idea.) The words here were carefully selected to mean exactly what is written. The text is not normalized because that would mean normalization of single, non-cluster codepoints. This would make it impossible to display CJK compatibility codepoints correctly since these are transformed under canonical normalization (despite their "compatibility" label). Japanese names can include these characters. > Or is the meaning that if the font has a glyph for the precomposed > character that is canonically equivalent to the sequence of characters, > then that glyph should be used (without changing the sequence of > characters itself). That would seem to make more sense. Yes, that's exactly what section 5.2 is addressing. For a *sequence* of codepoints, a glyph for a canonically equivalent character can be used. This is, in fact, already the norm for most modern layout engines. > Otherwise, it's not clear why you would select the font for this sequence. ??? Sorry, I don't quite get what you're saying here. Regards, John Daggett
Received on Friday, 13 September 2013 04:00:01 UTC