Bug 213772

Summary:

The preferred logical width of a text with line-break:anywhere doesn't take kerning into account

Product:

WebKit

Reporter:

Fujii Hironori <fujii.hironori>

Component:

Text

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Normal

CC:

ahmad.saleem792, mmaxfield, zalan

Priority:

Keywords:

BrowserCompat

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
test case	none
[screenshot] AppleWin port	none
[Screenshot] Safari TP 109	none
Safari vs Others	none

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?

alan

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.

alan

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.