Re: [css3-text] letter-spacing and degenerated grapheme clusters

On 01/17/2012 03:58 AM, Kang-Hao (Kenny) Lu wrote:
> (12/01/17 10:45), fantasai wrote:
>>
>>> 2. UAs render content with isolated surrogate differently. This already
>>> happened[1]. If you find other ways to address this problem (by either
>>> marking it as undefined or forbid certain behavior) then I think I am
>>> satisfied. That is, I don't want WebKit's behavior to fall into the "UA
>>> may further tailor the definition (grapheme cluster) as allowed by
>>> Unicode." allowance. UAs should not be allowed count a element starting
>>> with an isolated surrogate as having zero grapheme clusters so to speak.
>> CSS doesn't define how text maps to glyphs in the font, only which font
>> and font features you use to do it. So I would think that mapping is up
>> to the Unicode and font specs, not to up to CSS. I do expect that would
>> make WebKit's rendering wrong.
>
> Well, I was trying to "prove" that WebKit is wrong here with the
> machinery in this spec, the following logic flow and the "\udf06Test"
> example:
>
> * Establish the fact that this text run has at least four grapheme clusters.

This should be established by the Unicode definition of grapheme cluster.
If it's not, that's a bug in that spec, not CSS.

> * Write a test that uses "letter-spacing: 1em;" and check if this text
> run is at least 3em long.

Very clever. :)

> In this process, there's a relevant issue here I found. Namely, are UAs
> allowed not to count grapheme clusters if the underlying font systems
> drop these? For example, Opera12alpha* does not render replacement
> characters and the following two are equivalent:
>
> <div style="letter-spacing: 1em;">A&#xfffd;B</div>
> <!-- U+FFFD REPLACEMENT CHARACTER or any character the system don't
> support -->
> <div style="letter-spacing: 1em;">AB</div>
>
> Or, to draw it:
>
> A--B
>
> although I kind of expect it be at least
>
> A--|--B
>
> long according to spec. Similar example,
>
> <div style="letter-spacing: 1em;">AB</div>
> <div style="letter-spacing: 1em;">A&x200b;B</div>  <!-- U+200B ZERO WIDTH
> SPACE -->
>
> IE, FF9 and Opera12alpha shows the above two lines differently (A--B and
> A--|--B) while WebKit gives the same thing. Is WebKit allowed to exhibit
> this behavior because the underlying font system doesn't provide a glyph?

Whether the font has a glyph shouldn't make a difference to letter-spacing.
If the glyph is missing, typical behavior is to render a replacement glyph,
e.g. from the Last Resort Font.

> If that's the case, I would ask
>
> 1. The spec to clarify and say if the font system can't provide a glyph
> for a grapheme cluster, the grapheme cluster is allowed to be treated as
> if it's a degenerated one (the term in UAX#29). You might probably want
> clarify letter-spacing for degenerated grapheme clusters (mainly for Cc
> and Cf, since U+200B is Cf) too.

I don't think "degenerated grapheme cluster" is the right term here, since
A followed by an Indic combining mark is considered one.

I've added some text for zero-width characters, however.

> 2. The spec to define the what should happen for
>
> <a><b><c>TE</c>(no glyph)</b>ST</a>  for a { letter-spacing: 0.1em; } b {
> letter-spacing: 0.2em; }
>
> TE[0.2em]ST or TE[0.1em]ST
>
> because there are two boundaries.

This is already defined, see in particular the example:
   http://www.w3.org/TR/css3-text/#letter-spacing

> 3. The spec to say, in Appendix G, that default spacing (or at least
> letter-spacing) probably happens after font/glyph selection. I am not an
> implementer so I have no idea if this is making sense or not.

Normal letter-spacing is typically zero. Why should it be something else?

~fantasai

Received on Wednesday, 18 January 2012 02:06:59 UTC