WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
Bug 213772
The preferred logical width of a text with line-break:anywhere doesn't take kerning into account
https://bugs.webkit.org/show_bug.cgi?id=213772
Summary
The preferred logical width of a text with line-break:anywhere doesn't take k...
Fujii Hironori
Reported
2020-06-29 21:23:39 PDT
The preferred logical width of a text with line-break:anywhere doesn't take kerning into account
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 attachment
proposed patch, testcase, etc.
Fujii Hironori
Comment 1
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.
Fujii Hironori
Comment 2
2020-06-29 21:41:33 PDT
Created
attachment 403172
[details]
[screenshot] AppleWin port
Fujii Hironori
Comment 3
2020-06-30 21:47:58 PDT
Created
attachment 403262
[details]
[Screenshot] Safari TP 109
Fujii Hironori
Comment 4
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.
Ahmad Saleem
Comment 5
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?
zalan
Comment 6
2023-10-07 18:00:14 PDT
This is fixed. No extra space at the end of the second line. (IFC progression)
Ahmad Saleem
Comment 7
2023-10-07 18:04:57 PDT
Created
attachment 468110
[details]
Safari vs Others I get this in Safari vs other browsers.
zalan
Comment 8
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug