Closed Bug 1164835 Opened 10 years ago Closed 10 years ago

Vertical characters with orientation property Tr do not fallback correctly

Categories

(Core :: Graphics: Text, defect)

Product:
Core
Component:
Graphics: Text
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla41
Tracking Flags:
Tracking Status
firefox41 --- fixed

People

(Reporter: xidorn, Assigned: jfkthame)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Use vertical presentation forms (where available) in vertical-upright text as fallback if the font does not support the 'vert' feature
(deleted), patch
jtd
: review+
Details | Diff | Splinter Review
UTR#50 requires that, when displaying characters in vertical writing mode, the characters with vertical orientation property Tr generally use a different glyph from the font, but as a fallback, it can rotate the original glyph 90 degree clockwise. It seems we handle Tr the same as Tu characters, which by default keep upright. testcase: data:text/html;charset=UTF-8,<html style="writing-mode: vertical-rl; font-family:'Heiti SC'" lang="zh-TW">「测试」 The brackets here (U+300C, U+300D) are in category Tr. The font-family could be whatever font which doesn't include special glyph for the brackets. In my test, of Chinese fonts, I found only Hiragino Sans and Microsoft YaHei support the special glyphs, hence in other fonts the brackets are incorrectly put upright.
In CSS Writing Modes[1], we read # In the case of Tr characters, if such vertical alternate glyphs are missing from the font, the UA may # wish to [RFC6919] (but is not expected to) synthesize the missing glyphs by typesetting them sideways etc. While I agree it'd be good to implement a fallback here, I don't think this should block enabling vertical support. Note that there are a couple of aspects we should consider here. Currently, we apply the 'vert' OpenType feature and leave it up to the font to handle from there; if it doesn't support 'vert' alternates, we lose. However, if the font doesn't support 'vert', it is possible that it still has the necessary glyphs encoded in the Presentation Forms block (e.g. U+FE41, U+FE42). If these are present, we should use them. Then, only if the font lacks both the 'vert' feature AND the presentation-form codepoints would we need to try synthesizing the glyphs by typesetting sideways. [1] http://dev.w3.org/csswg/css-writing-modes/#typeset-upright
Blocks: writing-mode
No longer blocks: enable-writing-mode-release
(In reply to Jonathan Kew (:jfkthame) from comment #1) > In CSS Writing Modes[1], we read > > # In the case of Tr characters, if such vertical alternate glyphs are > missing from the font, the UA may > # wish to [RFC6919] (but is not expected to) synthesize the missing glyphs > by typesetting them sideways etc. I'm curious about why the spec doesn't expect UAs to follow what UTR#50 says here. > While I agree it'd be good to implement a fallback here, I don't think this > should block enabling vertical support. > > Note that there are a couple of aspects we should consider here. Currently, > we apply the 'vert' OpenType feature and leave it up to the font to handle > from there; if it doesn't support 'vert' alternates, we lose. > > However, if the font doesn't support 'vert', it is possible that it still > has the necessary glyphs encoded in the Presentation Forms block (e.g. > U+FE41, U+FE42). If these are present, we should use them. > > Then, only if the font lacks both the 'vert' feature AND the > presentation-form codepoints would we need to try synthesizing the glyphs by > typesetting sideways. If we do not implement the Presentation Forms block fallback for the first release, this bug could be fixed as easy as just changing one line of code. [1] I thought this should block enabling writing mode because vertical text is widely used in tranditional Chinese documents, while this issue causes really bad result on Chinese fonts, as most Chinese fonts do not support 'vert'. [1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxTextRun.cpp#2946
(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #2) > (In reply to Jonathan Kew (:jfkthame) from comment #1) > > In CSS Writing Modes[1], we read > > > > # In the case of Tr characters, if such vertical alternate glyphs are > > missing from the font, the UA may > > # wish to [RFC6919] (but is not expected to) synthesize the missing glyphs > > by typesetting them sideways etc. > > I'm curious about why the spec doesn't expect UAs to follow what UTR#50 says > here. jdaggett might have comments on this; IIRC, he was involved in discussions around this topic in the CSS WG. > If we do not implement the Presentation Forms block fallback for the first > release, this bug could be fixed as easy as just changing one line of code. I think it'll take a bit more than a single-line change; note that you'll want to handle not only text-orientation:mixed, which uses the UTR-50 lookup here, but also text-orientation:upright, which does not currently do any per-character orientation check. Also, I don't think we should apply sideways orientation if the font actually has support for 'vert' alternates, as we can reasonably expect that the font's vertical alternates may be designed/positioned more appropriately for use within vertical text. So we'd need to check for support in the font before choosing a resolved orientation here.
Here's a possible approach to this, at the text-shaping level. This does not handle all characters classified as 'Tr' in UTR-50, as not all of them have corresponding presentation forms encoded; nor does it help with fonts that don't provide the presentation forms at all. But I expect this would address the most common real-world use cases. Xidorn, could you confirm whether this fixes the issues you're seeing with typical content?
Attachment #8605888 - Flags: review?(jdaggett)
(In reply to Jonathan Kew (:jfkthame) from comment #4) > Xidorn, could you confirm whether this > fixes the issues you're seeing with typical content? Yes, it seems this patch fixes the problem properly in all Chinese fonts I have tested locally. Thanks for fixing that.
(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #0) > UTR#50 requires that, when displaying characters in vertical writing mode, > the characters with vertical orientation property Tr generally use a > different glyph from the font, but as a fallback, it can rotate the original > glyph 90 degree clockwise. We went round and round on this in the CSSWG and it boiled down to an argument between Koji and I about this. I objected to CSS requiring fallback for OpenType features, since it's a relatively complex operation to figure out whether or not a particular feature results in a glyph substitution and with well-designed fonts it's not necessary. Koji simply used his position as the editor of UTR50 to add that "requirement" into UTR50 instead. As I recall it's in the form of a comment at the header of the UTR50 data file. While I'm against trying to provide fallback for Tr codepoints for fonts with 'vert' implemented, I don't think what the patch here does is so bad, since it only tries to do fallback for fonts without 'vert'. I think Chinese fonts are often problematic in terms of feature support (e.g. inclusion of glyphs for Arabic without proper shaping info) but hopefully this patch covers the most problematic cases.
Attachment #8605888 - Flags: review?(jdaggett) → review+
(In reply to John Daggett (:jtd) from comment #7) > While I'm against trying to provide fallback for Tr codepoints for fonts > with 'vert' implemented, I don't think what the patch here does is so bad, > since it only tries to do fallback for fonts without 'vert'. Right; the idea here was to have a simple patch that addresses the common real-world case of fonts that simply don't have the feature. If a font has a 'vert' feature, but then doesn't actually implement it properly for the relevant characters, that's a broken font and we're not going to try and work around it on a per-glyph basis. (There's a somewhat comparable case within harfbuzz itself with regard to Arabic: if a font lacks the OpenType features, but has Presentation-Form characters, harfbuzz will use those. But if it has OT features, those will be used; and if they fail to cover all the characters, too bad -- no fallback is attempted.)
Assignee: nobody → jfkthame
https://hg.mozilla.org/mozilla-central/rev/fe6cd6a9e6a2
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: