Closed Bug 1431305 Opened 4 years ago Closed 4 years ago

Wavy Dash doesn't fall back to "rotated" in vertical writing-mode

Categories

(Core :: Layout: Text and Fonts, defect)

58 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: wareya, Assigned: jfkthame)

Details

Attachments

(2 files)

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
Attachment #8943653 - Flags: review?(m_kato) → review+
Pushed by jkew@mozilla.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
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 jkew@mozilla.com:
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
https://hg.mozilla.org/mozilla-central/rev/d76b88de07ca
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.