Closed Bug 1431305 Opened 4 years ago Closed 4 years ago
Wavy Dash doesn't fall back to "rotated" in vertical writing-mode
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180111124119 Steps to reproduce: Display text with 〰 in writing-mode: vertical-rl or vertical-lr Actual results: Character 〰 is displayed with wrong orientation if font doesn't have a typographic fallback MS Mincho has a typographic variation glyph for this character and renders it correctly in vertical text, fonts like Meiryo and Noto Sans CJK JP do not and so it renders incorrectly The attached image displays this. At this font size, MS Mincho is rendering bitmaps with different aliasing patterns for horizontal and vertical 〰, showing that it's a typographic transformation. 〰 should fall back to rotated in vertical text if there is no vertical glyph, as specified in https://www.unicode.org/Public/vertical/revision-17/VerticalOrientation-17.txt under codepoint 3030. Firefox currently doesn't even seem to propagate the difference between Tr/Tu in its code: https://github.com/mozilla/gecko-dev/blob/5c6d9cde5102ca89ce34bee7d3b98a8870e4b37c/gfx/thebes/gfxTextRun.cpp#L3181 And has a hardcoded list of fallbacks to other codepoints here: https://github.com/mozilla/gecko-dev/blob/230207fe301c422fa9daaa14e14edbd699dfa83d/gfx/thebes/gfxHarfBuzzShaper.cpp#L213 Related issue on HarfBuzz's bugtracker: https://github.com/harfbuzz/harfbuzz/issues/355 Expected results: Character 〰 should be displayed with a 90 degree rotation of its "upright" glyph if the font doesn't have a built-in typographic variation glyph of it for vertical text.
Component: Untriaged → Layout: Text
Product: Firefox → Core
This looks fairly easy to implement: by the time we resolve orientation, we have done font selection and so we can query the font to find out if it implements a 'vert' substitution for the character, and can also check if there's a vertical presentation form that would work as fallback; if neither of these is true, then we put the char into a rotated (sideways) run.
Attachment #8943653 - Flags: review?(m_kato)
Assignee: nobody → jfkthame
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/33571130ef67 Handle fallback (rotated) rendering of characters with Vertical_Orientation=Tr when the font does not support them via 'vert', nor is there a vertical presentation form encoded in Unicode. r=m_kato
Backed out changeset 33571130ef67 (bug 1431305) for failing in /text-orientation-mixed-vlr-100-ref.html on a CLOSED TREE https://hg.mozilla.org/integration/mozilla-inbound/rev/2648e1488e607d5f91e86008b6bbe9ca5d6a4e76 https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=2648e1488e607d5f91e86008b6bbe9ca5d6a4e76&filter-classifiedState=unclassified&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=running&filter-resultStatus=pending&filter-resultStatus=runnable
Ah, right -- it's possible for font selection to return null, if there's no font on the device that supports the given character. That must be the case on our Android test systems. So we need to check for that, and bail out of testing whether to do fallback-rotation or not (there's no point, we're just going to end up drawing a hexbox anyhow).
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/d76b88de07ca Handle fallback (rotated) rendering of characters with Vertical_Orientation=Tr when the font does not support them via 'vert', nor is there a vertical presentation form encoded in Unicode. r=m_kato
You need to log in before you can comment on or make changes to this bug.