RESOLVED CONFIGURATION CHANGED 123204
Combining vertical-rl writing mode, float: left and -webkit-text-combine: horizontal has unexpected result following r147588
https://bugs.webkit.org/show_bug.cgi?id=123204
Summary Combining vertical-rl writing mode, float: left and -webkit-text-combine: hor...
Antoine Quint
Reported 2013-10-23 06:37:15 PDT
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.
Attachments
Test case (455 bytes, text/html)
2013-10-23 06:37 PDT, Antoine Quint
no flags
Expected rendering of test case (39.84 KB, image/tiff)
2013-10-28 16:45 PDT, Antoine Quint
no flags
Test Case with longer text (573 bytes, text/html)
2013-11-02 03:40 PDT, Koji Ishii
no flags
Patch (225.48 KB, patch)
2013-11-19 21:34 PST, Yuki Sekiguchi
beidson: review-
Antoine Quint
Comment 1 2013-10-23 06:37:39 PDT
Glenn Adams
Comment 2 2013-10-23 08:52:07 PDT
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.
Koji Ishii
Comment 3 2013-10-27 10:34:23 PDT
(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.
Koji Ishii
Comment 4 2013-10-27 10:38:44 PDT
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.
Antoine Quint
Comment 5 2013-10-28 16:45:25 PDT
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.
Koji Ishii
Comment 6 2013-10-30 17:49:04 PDT
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.
Koji Ishii
Comment 7 2013-10-31 15:04:05 PDT
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...
Koji Ishii
Comment 8 2013-11-02 03:40:40 PDT
Created attachment 215806 [details] Test Case with longer text
Koji Ishii
Comment 9 2013-11-02 03:45:49 PDT
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.
Yuki Sekiguchi
Comment 10 2013-11-19 21:34:10 PST
Koji Ishii
Comment 11 2014-04-10 09:44:43 PDT
The patch from Yuki looks quite good to me. Can we get someone to review?
Brady Eidson
Comment 12 2016-05-24 22:05:22 PDT
Comment on attachment 217381 [details] Patch Assuming that patches for review since 2013 are stale, r-
Ahmad Saleem
Comment 13 2023-05-25 14:22:49 PDT
This seems to be working fine in WebKit ToT (264533@main) and it is matching with Chrome Canary 115.
Brent Fulgham
Comment 14 2024-01-22 14:57:38 PST
Closing based on Ahmad's testing.
Note You need to log in before you can comment on or make changes to this bug.