[Webkit-unassigned] [Bug 220548] Hairline on selection when bidi text is involved

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220548

--- Comment #5 from zalan <zalan at apple.com> ---
(In reply to Ebrahim Byagowi from comment #4)
> Created attachment 464685 [details]
> Hairlines
> 
> @zalan, this will be a nice polish to have I believe, the screen cast shows
> how reliably one can see hairlines on Persian Wikipedia's homepage,
> https://fa.wikipedia.org other than minimal tests I've brought it.
:| this is an unfortunate side effect of how we measure text at soft wrap opportunity boundaries and happily join such "runs" without remeasuring them ignoring kerning (and ligature) adjustments.

let's take the following example:
<span>ンズ</span>text
we form the following "runs" at soft wrap opportunities and measure them individually before line breaking
[ン] -> 16px
[ズ] -> 16px
[text] -> 42px
Later as we form the line, we merge [ン][ズ] into one run. This run now has the width of 32px but with potential kerning (and ligature) it may very well be (slightly) incorrect.
When we get to selection painting (as background decoration) we have the following runs:
[ンズ] -> left 0px, right 32px
[text] -> left 32px, right 74px
Now we want to be precise with the selection boundaries, so we call FontCascade::adjustSelectionRectForText() on these individual runs and due to kerning (and ligature) we may see a (slightly) different widths this time (note that we measure ンズ as one continuous run this time) 
[ンズ] -> 31.12px (and with directional pixel snapping -> 31.5px)
[text] -> 42px

and we paint selection at the following positions 
  from 0px to 31.5px
and
  from 42px to 74px

which ends up producing a hairline gap.

Now the correct fix is to never simply sum individual run widths when merging, but it has some performance (and line breaking cycle) implications afaict.
The more practical fix may be to never shrink selection rect through this adjustment. Need to do some code reading first.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230127/3d00e5c2/attachment-0001.htm>