Bug 213772 - The preferred logical width of a text with line-break:anywhere doesn't take kerning into account
Summary: The preferred logical width of a text with line-break:anywhere doesn't take k...
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: BrowserCompat
Depends on:
Blocks:
 
Reported: 2020-06-29 21:23 PDT by Fujii Hironori
Modified: 2023-10-07 18:46 PDT (History)
3 users (show)

See Also:

Attachments
test case (390 bytes, text/html)
2020-06-29 21:26 PDT, Fujii Hironori 		no flags Details
[screenshot] AppleWin port (7.78 KB, image/png)
2020-06-29 21:41 PDT, Fujii Hironori 		no flags Details
[Screenshot] Safari TP 109 (59.86 KB, image/png)
2020-06-30 21:47 PDT, Fujii Hironori 		no flags Details
Safari vs Others (419.05 KB, image/png)
2023-10-07 18:04 PDT, Ahmad Saleem 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fujii Hironori 2020-06-29 21:23:39 PDT 
The preferred logical width of a text with line-break:anywhere doesn't take kerning into account
Comment 1 Fujii Hironori 2020-06-29 21:26:18 PDT 
Created attachment 403171 [details]
test case

The first text has text-rendering:optimizeSpeed, and is rendered without kerning.
The second text has text-rendering:optimizeLegibility and line-break:anywhere, is rendered without kerning.
However, the second text computed its width without kerning and has the extra space.
Comment 2 Fujii Hironori 2020-06-29 21:41:33 PDT 
Created attachment 403172 [details]
[screenshot] AppleWin port
Comment 3 Fujii Hironori 2020-06-30 21:47:58 PDT 
Created attachment 403262 [details]
[Screenshot] Safari TP 109
Comment 4 Fujii Hironori 2020-10-01 14:11:30 PDT 
(In reply to zalan from bug #217136 comment #3)
> In LFC the preferred width computation and the actual layout share the same
> codepath with different constrains, so I'd say yes.
Comment 5 Ahmad Saleem 2023-10-07 15:12:00 PDT 
Chrome Canary 119 and Firefox Nightly 120 match each other in above test case while Safari Technology Preview 180 does not.

AppleWin port is gone though it still seems to be an issue.

@Alan - can we move it to 'Radar' to track it?
Comment 6 zalan 2023-10-07 18:00:14 PDT 
This is fixed. No extra space at the end of the second line. (IFC progression)
Comment 7 Ahmad Saleem 2023-10-07 18:04:57 PDT 
Created attachment 468110 [details]
Safari vs Others

I get this in Safari vs other browsers.
Comment 8 zalan 2023-10-07 18:46:48 PDT 
(In reply to Ahmad Saleem from comment #7)
> Created attachment 468110 [details]
> Safari vs Others
> 
> I get this in Safari vs other browsers.
Please file a bugzilla if you believe WebKit's optimizeLegibility implementation produces incorrect result here. By looking at the screenshot, it seems like we push for some advanced ligature, but I am no expert.