RESOLVED FIXED 220488
Make fast/text/international/complex-character-based-fallback.html more robust by migrating it to be a reftest instead of a DRT test
https://bugs.webkit.org/show_bug.cgi?id=220488
Summary Make fast/text/international/complex-character-based-fallback.html more robus...
Myles C. Maxfield
Reported 2021-01-08 16:41:13 PST
Make fast/text/international/complex-character-based-fallback.html more robust by migrating it to be a reftest instead of a DRT test
Attachments
Patch (554.72 KB, patch)
2021-01-08 16:43 PST, Myles C. Maxfield
no flags
Patch (556.01 KB, patch)
2021-01-08 16:54 PST, Myles C. Maxfield
no flags
Patch (556.06 KB, patch)
2021-01-08 16:57 PST, Myles C. Maxfield
no flags
Myles C. Maxfield
Comment 1 2021-01-08 16:43:16 PST
Darin Adler
Comment 2 2021-01-08 16:45:25 PST
Comment on attachment 417314 [details] Patch Could we convert the HTML files to UTF-8 instead of UTF-16?
Darin Adler
Comment 3 2021-01-08 16:52:45 PST
Can do it with this: iconv -f utf-16 -t utf-8 LayoutTests/fast/text/international/complex-character-based-fallback.html > temp.html mv temp.html LayoutTests/fast/text/international/complex-character-based-fallback.html Then probably need to add <meta charset="UTF-8"> to make sure it gets handled as UTF-8.
Myles C. Maxfield
Comment 4 2021-01-08 16:54:40 PST
Myles C. Maxfield
Comment 5 2021-01-08 16:57:29 PST
Myles C. Maxfield
Comment 6 2021-01-08 16:58:21 PST
The new files are UTF-8, but unfortunately bugzilla still thinks the test is a binary file (perhaps because the original version is UTF-16?).
Myles C. Maxfield
Comment 7 2021-01-08 16:58:51 PST
Darin Adler
Comment 8 2021-01-08 17:10:52 PST
Comment on attachment 417317 [details] Patch Are we always guaranteed to have the Latha font present?
Myles C. Maxfield
Comment 9 2021-01-12 14:56:59 PST
(In reply to Darin Adler from comment #8) > Comment on attachment 417317 [details] > Patch > > Are we always guaranteed to have the Latha font present? No. Unfortunately, I don't think there is a way to test font fallback without explicitly naming individual fonts. So, this patch makes us go from a test that was brittle and relied on an individual font, to a test that's less brittle and still relies on an individual font. A progression to be sure, but not perfect. I don't actually think adding an internals function to make sure that the right fallback functions are getting called would actually be better, as those fallback functions are just as much an implementation detail as these system fonts. Indeed, the presence of these language-support fonts likely changes less often than we change our font fallback code. So, with this patch, we're at a local maximum, and my claim is that our local maximum is also a global maximum.
EWS
Comment 10 2021-01-12 15:13:20 PST
Committed r271419: <https://trac.webkit.org/changeset/271419> All reviewed patches have been landed. Closing bug and clearing flags on attachment 417317 [details].
Note You need to log in before you can comment on or make changes to this bug.