Fixed width font size not consistent for elements containing a long string
Reported by
koh.shim...@mathworks.com,
Jun 20 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3136.0 Safari/537.36 Steps to reproduce the problem: 1. Open attached file, FontBug.html, which contains four identical lines of text in a single div. 2. Scroll all the way to the right 3. Observe that the fourth line of text is a different length than the previous lines. What is the expected behavior? All four lines should be the same length What went wrong? The fourth line is a different length as shown in result.png Did this work before? N/A Does this work in other browsers? Yes Chrome version: 61.0.3136.0 Channel: canary OS Version: 10.0 Flash Version: Shockwave Flash 26.0 r0 I suspect that this is happening when there are more than 2^16 characters in a single element. But it is difficult to find the exact point where this starts because the shift in position is so subtle. Not sure if it is related, but issue 155241 also involved rendering problems after 65K characters. Works as expected in IE11, Edge, and Firefox
,
Jun 21 2017
We should probably split long strings into multiple TextNodes.
,
Jun 22 2017
I did look at this some: - each row is 20K chars - the problem occurs on the 4th row, which is crossing 64K - e.g. if we add another row, the problem is still on the 4th row: https://codepen.io/fmalita/pen/vZZaoJ I think what's going on is float error accumulation: the 4th row is split into two bidi runs (https://codereview.chromium.org/853903002), so we have two inline text boxes, unlike the other rows. One is some ~5.4K, the other one is ~14K. As we're building the blob for the latter, we're accumulating advances starting at a different offset than the other rows - and since the multiplier is so large, the precision drift is compounding/growing. One observation is that we should not have split that row in the first place (a line box can handle 20k chars), but the 64k limit it enforced early on in the bidi iterator. A possible fix would be to always pass down a line origin, and use that as for advance accumulation - such that all glyphs are positioned in the same space - and then adjust individually. Then I think we'd avoid the compound precision drift.
,
Jun 22 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 28 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Jun 21 2017Components: Blink>Fonts
Labels: -Type-Bug -Pri-2 M-61 hasbisect OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: fmalita@chromium.org
Status: Assigned (was: Unconfirmed)