[webkit-reviews] review granted: [Bug 17427] Line breaking opportunities at the end of a text node are missed : [Attachment 172268] Proposed patch v6

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Nov 4 22:06:17 PST 2012


Alex Henrie <alexhenrie24 at gmail.com> has granted  review:
Bug 17427: Line breaking opportunities at the end of a text node are missed
https://bugs.webkit.org/show_bug.cgi?id=17427

Attachment 172268: Proposed patch v6
https://bugs.webkit.org/attachment.cgi?id=172268&action=review

------- Additional Comments from Alex Henrie <alexhenrie24 at gmail.com>
I've spent more time on this and, unfortunately, have not come up with anything
workable. The entire system, from acquireLineBreakIterator to
LazyLineBreakIterator to nextBreakablePosition, is designed to work with a
single string. If you wrap the nodes in a UText and take away the ability to
see a single string then multiple problems arise, the most obvious being that
there is no way to have the algorithm treat NBSP as a simple space. If you try
to fix this problem by passing around the list of nodes as well as the iterator
over them, you run into the difficulty of having to find a way to remember and
tell all these functions which node and which index within that node they are
on, as well as the difficulty of rewriting everything to use a list instead of
a string.

Furthermore, writing the necessary functions for pFuncs is nontrivial even with
Michael's code as an example. In the implementation of UTextAccess, if the last
character of a chunk is requested "going forward" then a new, temporary chunk
must be created from the end of the current chunk and the start of the next
chunk. According to the ICU documentation, this new chunk MUST "begin and end
on code point boundaries" and "a single code point comprised of multiple
storage units must never span a chunk boundary." The same complication arises
when the first character of a chunk is requested "going backward".

I also learned recently that in addition to the previously listed problems that
this bug is causing, the combination of this bug and bug 76131 causes incorrect
rendering of Google Translate's yellow highlighting if, at a non-space line
break in the textbox, a newline is added and then deleted.

I've rebased the StringBuilder patch against the current tree. I realize that a
more efficient ICU solution is theoretically possible, but due to the massive
complexity of such a solution and lack of willing developers I just don't see
it happening. StringBuilder is designed to minimize memory reallocations, so
the performance shouldn't be terrible. Performance might be further improved by
changing LazyLineBreakIterator to take a pointer to the string instead of
recopying the string.

If there is someone out there who can come up with something better that works,
please come forward...


More information about the webkit-reviews mailing list