RESOLVED FIXED229572
[GLIB] mark fast/text/trak-optimizeLegibility.html as a skip
https://bugs.webkit.org/show_bug.cgi?id=229572
Summary [GLIB] mark fast/text/trak-optimizeLegibility.html as a skip
Arcady Goldmints-Orlov
Reported 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.
Attachments
Patch (3.28 KB, patch)
2021-08-26 13:13 PDT, Arcady Goldmints-Orlov
no flags
Myles C. Maxfield
Comment 1 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.
Myles C. Maxfield
Comment 2 2021-08-26 12:01:51 PDT
*messed
Myles C. Maxfield
Comment 3 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.
Myles C. Maxfield
Comment 4 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.
Myles C. Maxfield
Comment 5 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.
Arcady Goldmints-Orlov
Comment 6 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.
Arcady Goldmints-Orlov
Comment 7 2021-08-26 13:13:46 PDT
Myles C. Maxfield
Comment 8 2021-08-26 13:26:40 PDT
Comment on attachment 436555 [details] Patch 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.
EWS
Comment 9 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].
Radar WebKit Bug Importer
Comment 10 2021-08-26 14:17:18 PDT
Note You need to log in before you can comment on or make changes to this bug.