Closed Bug 700022 Opened 9 years ago Closed 7 years ago
add reftests for Graphite font shaping with various types of script behavior
57.86 KB, text/html
259.41 KB, patch
|Details | Diff | Splinter Review|
6.08 KB, patch
|Details | Diff | Splinter Review|
(Split off from bug 631479.) We should add reftests using a variety of Graphite-enabled fonts. This will require us to turn on the graphite pref in order to have the tests running on mozilla-central. Bug 696585 proposes a mechanism to turn it on for specific tests, so that we can do this before we're ready to enable graphite by default.
These are the same basic tests as were originally posted in bug 631479, updated to use the pref-switching support from bug 696585. I'll also prepare some additional testcases using different graphite-enabled fonts.
Assignee: nobody → jfkthame
Attachment #572463 - Flags: review?(jdaggett)
Some tests for HTML lang support, using the Graphite version of Scheherazade. Note that the font supports both 'ur' and 'urd' for Urdu, and both 'sd' and 'snd' for Sindhi; the tests here verify that only the 2-character (BCP47) form is recognized, and the 3-character (iso639-3) tag does _not_ access the language-specific rendering in the font, as per discussion in bug 631479.
Attachment #572488 - Flags: review?(jdaggett)
Review ping? Now that bug 696585 has landed, it'd be nice to have tests in the tree to verify Graphite is actually working when the pref is turned on.....
The problem with graphite-02 is the structure of the reference HTML. It looks like we have some sort of problem related to our ZWNJ handling, note how the reference case has an entire pixel clipped at the bottom of each glyph.
Comment on attachment 572463 [details] [diff] [review] part 1 - initial graphite reftests, moved over from bug 631479 I think a simpler way to deal with the graphite-02 failure under DirectWrite is to make another version of the same font without the Graphite tables and then remove the zwnj from the reference. In addition, running the graphite03a reftest crashes within the reftest environment. If you can't reproduce then I'll try and debug it.
Attachment #572463 - Flags: review?(jdaggett) → review-
Also, several of the graphite-05 tests are failing on fedora: http://firstname.lastname@example.org/try-linux64/try_fedora64_test-reftest-build1427.txt.gz Looks like a 1-pixel shift between Ss.
Updated simple graphite tests. (These require the fixes from bugs 831277, 831292 and 831687 to pass correctly across all platforms.)
Attachment #703388 - Flags: review?(jdaggett)
Rebased patch for graphite language-tagging tests, carrying forward r=jdaggett.
Attachment #572463 - Attachment is obsolete: true
Attachment #572488 - Attachment is obsolete: true
We already landed a copy of the graphite-enabled Scheherazade font in bug 772640, so we can just use that one rather than adding a separate version of the file here. Removed the font file from this patch, and updated the font filename in the tests accordingly (the actual tests themselves are unchanged). Carrying over r=jdaggett.
Attachment #703390 - Attachment is obsolete: true
Target Milestone: --- → mozilla21
This seemed to cause failure on android/b2g in later tests (whatever happens to be running when the graphite fonts are being expired from cache, I think). Backed out, pending further investigation: https://hg.mozilla.org/integration/mozilla-inbound/rev/0a25461c8e97
Re-landed these tests, as bug 843588 should resolve the crashiness we saw last time. https://hg.mozilla.org/integration/mozilla-inbound/rev/f97bc1de213a https://hg.mozilla.org/integration/mozilla-inbound/rev/ac6dff6a0811
Target Milestone: mozilla21 → mozilla22
Backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/5f688e2b37dc for the day-long permaorange b2g reftest-6 of bug 844165.
Target Milestone: mozilla22 → ---
I don't see any "valid" way this landing can have caused that test failure - the b2g reftest-6 job doesn't even run any of the layout/reftests/text/* tests, they're in a completely different chunk. Also, I notice that the same R6 failure has reappeared, looking equally perma, just a few pushes -after- these were backed out. So I'm going to claim this was an innocent victim of the flakiness of b2g tests, and propose to re-land it once the tree's open again. If necessary, I'll mark the tests skip-if(b2g) to try and reduce the risk of disturbing that whole house of cards again.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
You need to log in before you can comment on or make changes to this bug.