Make fast/text/international/complex-character-based-fallback.html more robust by migrating it to be a reftest instead of a DRT test
Created attachment 417314 [details] Patch
Comment on attachment 417314 [details] Patch Could we convert the HTML files to UTF-8 instead of UTF-16?
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.
Created attachment 417316 [details] Patch
Created attachment 417317 [details] Patch
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?).
<rdar://problem/70556068>
Comment on attachment 417317 [details] Patch Are we always guaranteed to have the Latha font present?
(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.
Committed r271419: <https://trac.webkit.org/changeset/271419> All reviewed patches have been landed. Closing bug and clearing flags on attachment 417317 [details].