Bug 229572 - [GLIB] mark fast/text/trak-optimizeLegibility.html as a skip
Summary: [GLIB] mark fast/text/trak-optimizeLegibility.html as a skip
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Linux
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2021-08-26 10:11 PDT by Arcady Goldmints-Orlov
Modified: 2021-08-26 14:17 PDT (History)
3 users (show)

See Also:

Patch (3.28 KB, patch)
2021-08-26 13:13 PDT, Arcady Goldmints-Orlov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arcady Goldmints-Orlov 2021-08-26 10:11:40 PDT
This test is checking that the rendering with optimizeLegibility is different from the default rendering when using a font with the 'trak' table included for custom tracking information. Harfbuzz does support using this table, so I think this test should pass on GLIB.
Comment 1 Myles C. Maxfield 2021-08-26 12:01:34 PDT
There’s a chance I missed up the font when I generated it, too. If that’s the case, please let me know; I’m happy to fix the font.
Comment 2 Myles C. Maxfield 2021-08-26 12:01:51 PDT
Comment 3 Myles C. Maxfield 2021-08-26 12:06:15 PDT
Oh, I bet optimizeLegibility just isn’t hooked up to anything on the HarfBuzz ports. We implement this by passing a magic flag into CoreText.

I guess it’s up to each port what they want optimizeLegibility to mean. The right fix here might to be to intentionally mark this test as only passing on some ports, if other ports want to use optimizeLegibility to do something different.
Comment 4 Myles C. Maxfield 2021-08-26 12:09:27 PDT
Some more context: this trak thing isn’t necessary for web compatibility. It’s here because Apple teams wanted to serve San Francisco as a web font so it would work on Windows computers, and SF has a trak table, and they wanted to have some way to opt-in to making it work. It would be totally reasonable for a port to say they are uninterested in hooking up optimizeLegibility to trak. Or, if a port wants to enable trak unconditionally. It’s up to each port.
Comment 5 Myles C. Maxfield 2021-08-26 12:11:45 PDT
*isn’t necessary for _general_ web compatibility. It was a specific request from specific (high profile, at least to our port) sites.
Comment 6 Arcady Goldmints-Orlov 2021-08-26 13:10:06 PDT
Upon further investigation, I think this test needs to be skipped on Linux because I don't think optimizeLegibility is hooked up to anything, or rather I think it's always on since all text goes through the complex path. And upon examination it does look like HarfBuzz tries to read and use the trak in fonts that have one. I am going to reuse the bug for the gardening patch to skip this test.
Comment 7 Arcady Goldmints-Orlov 2021-08-26 13:13:46 PDT
Created attachment 436555 [details]
Comment 8 Myles C. Maxfield 2021-08-26 13:26:40 PDT
Comment on attachment 436555 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=436555&action=review

> LayoutTests/platform/glib/TestExpectations:1771
> +fast/text/trak-optimizeLegibility.html [ Skip ]

Actually skipping the test can hide crashes. Usually it's better to mark them as either passing or failing (or, if you want to be notified of progressions, mark as just failing), so we can make sure they don't crash.
Comment 9 EWS 2021-08-26 14:16:37 PDT
Committed r281653 (241008@main): <https://commits.webkit.org/241008@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 436555 [details].
Comment 10 Radar WebKit Bug Importer 2021-08-26 14:17:18 PDT