Created attachment 214954 [details] Test case See the attached test case, which started rendering differently following http://trac.webkit.org/changeset/147588, a fix for https://bugs.webkit.org/show_bug.cgi?id=105692.
<rdar://problem/15297778>
This appears to be a case where, due to the transition to and from tatechuyoko (horizontal within vertical) mode, the line breaking context across the transition boundary should be cleared, i.e., you want to use: m_renderTextInfo.m_lineBreakIterator.resetPriorContext(); at the the transition boundary.
(In reply to comment #2) > This appears to be a case where, due to the transition to and from tatechuyoko (horizontal within vertical) mode, the line breaking context across the transition boundary should be cleared, i.e., you want to use: > > m_renderTextInfo.m_lineBreakIterator.resetPriorContext(); > > at the the transition boundary. The proposed fix here doesn't look correct; resetting line break context should not occur at inline element boundaries nor at before/after tatechuyoko. See: # For line breaking before and after the composition, # it is treated as a regular inline with its actual contents. http://dev.w3.org/csswg/css-writing-modes/#text-combine-layout I looked at the test case file, but from this bug description, the result and the expected is not clear to me.
oops, hit Enter too early; I mean, I wonder maybe this is by design. Antoine, can you clarify your expectations? I can then comment more properly.
Created attachment 215346 [details] Expected rendering of test case Attached a screenshot of my expectation, which matches what WebKit used to render up to r147588.
hm, the original looks more natural, but there should be a break opportunity before "1". I guess I need to look into more, but I suspect there has been a bug in box layout, and bug 105692 fix was right, but it brings hidden bug up. I'll look further later.
I can't say exactly how and where, but my best guess is that intrinsic size calculation is incorrect when a vertical span contains a horizontal span, and Glenn's change made the bug clearer. When tatechuyoko appears at the end of line, there should be break opportunities before and after. Exceptions are like when "!?" is in the tatechuyoko, because break before "!" is prohibited as per UAX#14. I feel sorry that I guess this isn't really helpful advice...
Created attachment 215806 [details] Test Case with longer text
See "Test Case with longer text"; this should not wrap, and is not related with bug 105692 (I suppose; I don't have older build.) So a wild guess is that: 1. WebKit has a bug to calculate intrinsic size. A guess from the test case is that, it calculates character advances without writing-mode or tatechuyoko in mind. In the case of the attached test case, it might add *height* of "1", not *width*, and thus resulting box is smaller and lead to line break. 2. In the case of the attached test case, it does not break, there were no break opportunity. 3. With bug 105692 fixed, now the line has a break opportunity, and the original bug appear. So, having a line break opportunity is correct, and we need to attack the original bug.
Created attachment 217381 [details] Patch
The patch from Yuki looks quite good to me. Can we get someone to review?
Comment on attachment 217381 [details] Patch Assuming that patches for review since 2013 are stale, r-