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

(12/01/17 20:37), Jonathan Kew wrote:
> On 17 Jan 2012, at 11:58, Kang-Hao (Kenny) Lu wrote:
>> 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?
> I don't think so.

I kind of like this direction actually since it's easier to understand.
Let's talk about the "push everything to the font system" plan later if
browsers don't converge on this.

>> 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.
> Perhaps it should result in T[0.2em]E[0.15em]S[0.1em]T, because the right-hand sidebearing of E is increased by half the letter-spacing of element b, while the left-hand sidebearing of S is increased by half the letter-spacing of element a.

I just realized that this is actually well defined in the spec. For example,

<a><b><c>A</c></b>B</a> would give

A[0.1em]B because the spec currently uses the common ancestor's
'letter-spacing'. And even

<a><b><c>A</c>(U+0001, <control>)</b>B</a> gives

A[0.1em]B because control characters are removed far before white space
processing:

[[Control characters (Unicode class Cc) other than tab (U+0009), line
feed (U+000A), space (U+0020), and the bidi formatting characters
(U+202x) are ignored for the purpose of rendering. ]]
(This is not quite reality-reflecting at the moment though.)

I think this behavior is actually better than your half-half
interpretation, although I don't have strong opinion. After all, I don't
have real world use cases of this besides writing an automated test case
that fails WebKit (for the surrogate thing) :p.


Cheers,
Kenny

Received on Tuesday, 17 January 2012 14:28:07 UTC