Bug 169613
| Summary: | tryHyphenating's maxPrefixWidth computation is odd. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | alan <zalan> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bfulgham, hyatt, koivisto, mitz, mmaxfield, simon.fraser, zalan |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
alan
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
alan
> hyphenating, but since this value is inflated by the trailing whitespace, we
and I meant leading whitespace.