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.
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.
*messed
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.
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.
*isn’t necessary for _general_ web compatibility. It was a specific request from specific (high profile, at least to our port) sites.
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.
Created attachment 436555 [details] Patch
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.
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].
<rdar://problem/82407020>