[Webkit-unassigned] [Bug 169613] New: tryHyphenating's maxPrefixWidth computation is odd.

[bugzilla-daemon at webkit.org]

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

            Bug ID: 169613
           Summary: tryHyphenating's maxPrefixWidth computation is odd.
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: zalan at apple.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

I wonder why
1. the xPos in-param value is not set to the position of the hyphenated string but instead it is set to one character before.
Most of the time it's a space (whitespace) but it can also be a sequence of non-collapsed whitespace like tabs.
case 1: non-collapsed whitespace -> "tabtabstring", xPos -> "tab|tabstring" 
case 2: collapsed whitespace "spacestring", xPos -> "|spacestring"
3. then we do "availableWidth - xPos - hyphenWidth" where the "availableWidth - xPos" is supposed to indicate the width we have for hyphenating, but since this value is inflated by the trailing whitespace, we try to compensate for that by subtracting hyphenWidth. (that's just a guess, but I can't figure out a better explanation, not even through blame)
I just don't see how these values add up and why can't we pass in the actual width left for the string and see if the hyphen fits.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170314/97a80fbf/attachment.html>