[css-text] Letter spacing is inserted after RTL reordering

[kojiishi]

The last example of Example 16 in letter-spacing property says:

Letter spacing is inserted after RTL reordering

But letter-spacing affects line breaking, so we need to compute before line breaking.

Is this saying, compute once for line breaking in logical order, then re-compute after line breaking in visual order? Then the line width will not match and it may result in large-lagged lines, correct?

Test: http://output.jsbin.com/hudaxi

[fantasai]

Technically, bidi reorder affects line breaking as well, since adjacent letters can have kerning and other effects that alter their width. :) This is not a different consideration. Letter-spacing is at least more predictable than that.

[kojiishi]

We don't compute kerning/joining/etc. using adjacent characters after re-order for the same reason. The current engine can't do it across bidi runs, new engine does it in logical order. Doing them after re-order looks degration to me.

Thank you for the comment, your comment confirmed I'm not misunderstanding nor misreading (unless I'm still misunderstanding something...)

[kojiishi]

I heard Mozilla is going to implement this, is that correct? @dbaron @SebastianZ

At first this was asking clarification but now we seem to have the same understanding, just different opinion which is more important.

Do other impls have opinions? @litherum @FremyCompany

[FremyCompany]

I haven't seen letter-spacing usages in the wild that require complex rules for it.

That doesn't mean there are no such use cases; but I think due to widespread abuse letter-spacing is not a good candidate for being "fixed" at this point.

[kojiishi]

Thank you @FremyCompany, I'm hearing similar feedback from our engineer too.

I don't know the whole issue list the current design is trying to solve, maybe the list is much longer than I'm guessing. I'm hoping, in Paris, we try to learn the history from whoever knows and discuss 1) whether compat is needed or not, and 2) given that information, possible simplification of the algorithm by focusing more important issues in existing impls.

I hope we can reach consensus easier if this is compat with existing impls, and additions are simpler.

[css-meeting-bot]

The CSS Working Group just discussed Applying letter-spacing after line breaking.

The full IRC log of that discussion

<TabAtkins> Topic: Applying letter-spacing after line breaking
<Rossen> github topic: https://github.com//issues/1509
<TabAtkins> koji: As fantasai just mentioned, diff between CSS2 and CSS3 is that 3 says apply l-s after bidi-reorder.
<TabAtkins> koji: But bidi-reorder applies after line-breaking,
<fantasai> CSS2.1 implied after bidi-reorder. L3 specifies explicitly
<TabAtkins> koji: Which can change the number of "between" spaces there is to add letter-spacing.
<TabAtkins> koji: So after we add letter-spacing, the line width can change, shorter or longer.
<TabAtkins> koji: So I think this is a worse issue than what it's trying to solve.
<TabAtkins> fantasai: You ahve to include the letter-spacing when figuring out sapcing and line-breaking.
<TabAtkins> fantasai: This is same as kerning.
<TabAtkins> koji: We don't redo kerning after bidi.
<TabAtkins> koji: Because changing line widths after break is really bad.
<TabAtkins> fantasai: Yeah, def don't want to change line-width afterwards, that's bad.
<TabAtkins> fantasai: So that measn you have to consider letter-spacing before breaking the line.
<TabAtkins> fantasai: But since bidi-reordering happens after breaking the line, you won't know where the letter-sapcing goes until after doing the reordering.
<TabAtkins> myles_: Do you have an example of this breaking?
<TabAtkins> koji: [looks it up]
<TabAtkins> koji: Last bit of example 16 in Text.
<TabAtkins> koji: There's a 2em spaccing between the characters in the span, but reordering separates the letters.
<TabAtkins> myles_: I understand now.
<TabAtkins> fantasai: If you have that example, bidi-reordering puts two letters nexxt to each other that weren't next to each other logically, do you perform shaping and kerning between them?
<TabAtkins> myles_: Ours won't cross bidi boundaries.
<TabAtkins> koji: We're trying to do better at shaping across element boundaries, but only in logical sequences, before bidi reordering.
<TabAtkins> koji: I believe we're trying to match Gecko's behavior.
<TabAtkins> fantasai: Yeah, difficult; we're splitting up letters in an element, so where does the letter-spacing go?
<TabAtkins> fantasai: Per spec, you don't put the letter spacing between letters of the element and letters outside the element.
<TabAtkins> fantasai: So I see you point that it's hard to measure correctly.
<TabAtkins> koji: If we follow Edge/WK impl and resolve the previous l-s topic, there should be 2em space on the right of C.
<TabAtkins> TabAtkins: line-right edge - in logical order, it separates the letter from the next logical letter.
<TabAtkins> fantasai: Example: you ahve a para with 1em letter spacing. Inside you have a span with 0 l-s. Between the last letter of the span and first letter outside the span, there's 1em letter spacing, where does that attach?
<TabAtkins> <p>f_o_o<span>bar</span>_f_o_o</p>
<TabAtkins> fantasai: Another span with borders and padding. You do linebreaking calcs.
<TabAtkins> fantasai: Then you cut the line and do bidi reordering, but it has b-d-b: clone. Now you have two pieces with padding around them, where befor eyou had only one. Now what?
<TabAtkins> <p>f_o_o_<span>bar</span>_f_o_o</p>, rather
<TabAtkins> koji: I was reading b-d-b for the first time this morning, and thought of that exact problem.
<TabAtkins> dbaron: Okay, at bidi *resolution* time, the element would split into two separate fragments, and thus both get borders.
<TabAtkins> koji: But you don't know how linebreaking will happen yet.
<TabAtkins> TabAtkins: If there's only enough room for 4 letters, so the "c" and the aleph are next to each other, is that still two independent spans?
<TabAtkins> dbaron: We don't unclone them - they stay separate fragments.
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2F
<dbaron> p%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292
<TabAtkins> dbaron: That might not be an intentional decision; they might have thought about it as normal linebreaking and this behavior just falls out.
<TabAtkins> fantasai: I think it's okay to allow impls to do that.
<fantasai> TabAtkins: So the c and aleh would still be considered separate fragments, even though they are adjacent
<fantasai> TabAtkins: and the letter-spacing between them would be controlled by the parent
<fantasai> fantasai: I like this solution
<fantasai> TabAtkins: Wouldn't be too complicated, and would give sensible results in most cases and sensible-enough results in the rest
<fantasai> TabAtkins: During bidi resolution, you split them into separate fragments, and behavior falls out from that
<TabAtkins> koji: So we'll lose the letter sapcing between bidi runs.
<TabAtkins> TabAtkins: If the bidi runs are in the same element, yes - they'll use the parent's letter-spacing.
<fantasai> Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking.

Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking.

Behavior for letter-spacing (and other things affected, like box-decoration-break), falls out of this definition: in this case, if the two letters end up adjacent but are part of different fragments, the spacing between them will be given by the parent (according to the letter-spacing rules that control letter-spacing at element boundaries). This avoids the measuring problem.

[kojiishi]

@fantasai can you help to understand? I understand the proposal solves border-decoration-break: clone, but I can't see how it solves letter-spacing. By looking at Example 16, so the proposal is to create (assume <f> is the internal fragment):

<p><f>ab</f><span><f>c</f><f>א</f></span><f>בג</f></p>

The common ancestor of c and ג is <p>, so there will be no 2em spacing in the result, if I'm not mistaken.

Or is your proposal includes to change to check logical adjacent character instead of visual adjacent character? Then between c and א has 2em space, but I can't read from the current spec where that space should go after re-order. Should it be re-ordered along with c or א?

Could you point out what I missed?

For your question in F2F, if we were to say "apply to line-right of characters", we could say, for the last character, apply the spacing of common ancestor. I'm ok to use the current way to define it if you can make it to work, but if you prefer the line-right solution, I hope this can work.

[fantasai]

Talked with Koji; Agenda+ to resolve on proposal in #1509 (comment)

[FremyCompany]

I see the Agenda+ but I don't see an example explaining this new proposed algorithm. I'd like an image explaining this if possible, or at least a more detailed proposal, because I'm not confident on resolving on something I don't understand.

[fantasai]

@FremyCompany It means that in Koji's example above, if we ignore the <f> bits:

<p>ab<span>cא</span>בג</p>

Because the span will split into two fragments due to bidi reordering on an infinite line, then even if the last two letters don't fit and the two pieces happen to end up together, they are considered to be of two different fragments, and the space between the two letters will be considered to come from the P (the letters’ nearest common ancestor).

[css-meeting-bot]

The Working Group just discussed Letter spacing is inserted after RTL reordering, and agreed to the following resolutions:

• RESOLVED: if bidi resolution would result in splitting an inline in infinite space, it creates 2 fragments even if they end up adjacent due to line breaking.

The full IRC log of that discussion

<dael> Topic: Letter spacing is inserted after RTL reordering
<dael> github: https://github.com//issues/1509
<fantasai> https://github.com//issues/1509#issuecomment-371384680
<dael> Rossen: koji brought this up, we discussed, and it's back again. Proposal is to resolve on #105
<dael> Rossen: This comment from fantasai
<dael> s/105/1509
<fantasai> “Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking.
<fantasai> Behavior for letter-spacing (and other things affected, like box-decoration-break), falls out of this definition: in this case, if the two letters end up adjacent but are part of different fragments, the spacing between them will be given by the parent (according to the letter-spacing rules that control letter-spacing at element boundaries). This avoids the measuring problem.”
<dael> myles: I'm a little confused about what fantasai said
<dael> fantasai: Issue was that let's say the p has letter spacing of 2ema nd span has 0. As you try and layout the line you try to...you stop laying out when you run out of space. If the point wher eyou break introduces space as how the bidi reordering happens and then you add 2em to what the chracters take up your line layout is confused. For tex tyou want a predictable amount of space.
<dael> fantasai: What happens here is bidi reordering splits the span. You have abc and 123 and they'll be 321 in left to right. Last 2 characters are 3 and 2 and they push to another page. 3 and 2 were separating the b and c so letter spacing came from the <p> When you take out the 2 and 3 you get the c and 1 next to.
<dael> fantasai: Now that they're both a part of the span do you take the spacing from the span or the p. If you take from the span it's unpredictable
<dael> fantasai: proposal is when you know the span will split you make that be an element boundary always. Even if they end up nex to each other. Letter spacing between those needs to use the nearest common ancestor which is the <p> That's consistant with what spacing you would use if you have more space on the line.
<dael> fantasai: That's what we're trying to solve. Get a consistant idea of how much spacing is used for each letter.
<dael> myles: I think that's what webkit does as I understand. We'll break the c and 1 into separate objects. Later realizing they're 2 objects and apply letter spacing indenendant. If I understand.
<dael> fantasai: All impl don't handle the bounderies well. We have problems with letter spacing at the end of the line which makes authors unhappy. Spec is clear about no letter spacing at the end of the line or after an element. No one has that impl, but if you do letter spacing is tied to a pair of letters and needs to be determined by the nearest ancestor of those letters. So we need a more sophisticated letter.
<dael> myles: It's coming abck to me. I agreed to investigate in Paris and I still want to do so. I think I said in Paris I'd do it in a year and I'm still in that window ^-^
<dael> fantasai: We never resolved so we do need a resoution to do this.
<dael> Rossen: I was trying to read minutes, sounds like there was agreement. myles your investigation, are you okay to resolve now?
<dael> myles: Oh, yeah, we can resolve now. If I investigate and it's all wrong we can change.
<dael> Rossen: Proposal: bidi resolution will result in splitting an inline finante space and already create 2 fragments even if they end up adjacent.
<dbaron> yeah, I'm fine with this -- Gecko does this sort of splitting already
<dael> Rossen: Objections?
<fantasai> :)
<dbaron> we just don't do the letter-spacing thing yet
<dael> RESOLVED: bidi resolution will result in splitting an inline finante space and already create 2 fragments even if they end up adjacent.
<dael> Rossen: We're at the top of the hour.

[fantasai]

Fixed by adding a new subsection to the section on the effects of bidi on the inline box model in CSS Writing Modes. (Sorry, but this was the most logical place to put it.) https://drafts.csswg.org/css-writing-modes-3/#bidi-box-model

[fantasai]

@kojiishi @FremyCompany Let me know if the new text is sufficiently clear?