Fallback vertical shaping

[khaledhosny]

Firefox tries to use vertical presentation forms when the font lacks ‘vert’ feature. Based on the mailing list discussion HarfBuzz should do it.

[KrasnayaPloshchad]

This is helpful for in some adaptations uses vertical only text layout. For example, on this page several CJK punctuations are used as quote mark for Mongolian text, when they display with Oyun Qagan Tig, they looks unrotated, but when they display with Mongolian Baiti, they looks rotated. BTW Is it possible to let developer disable it if this function is implemented?

[kojiishi]

Out of curiosity, why do you want to disable it?

[KrasnayaPloshchad]

I think this can be configure via an additional API.

[behdad]

No need to make it configurable. If we were to add API for everything, the library would have been unusably complex.

[KrasnayaPloshchad]

This would be helpful for some non-CJK fonts. For example, Oyun Qagan Tig does not have 'vert' feature for U+3008-U300B, Abkai Xanyan does not have the same feature for U+300C-U300F. To get predictable appearence, provide fallback shaping for them would be helpful.

[khaledhosny]

I tried to address the underlying issue differently in LibreOffice:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=0f3861e65d8e652dcc31cf9a2f2b5c1a0a73b86d

Namely, collecting all the output glyphs from vert feature and if the glyph for a character with Tr is not in that set, I rotate it. This might be a little hacky, but it gives better results with fonts not having complete coverage in vert feature, or fonts without a vert feature at all but the vertical presentation forms glyphs are drawn upright like the Oyun Qagan Tig font above.

[khaledhosny]

Now I realize that if HarfBuzz implemented the fallback vertical shaping, my solution will rotate the fallback presentation forms glyphs. Well unless HarfBuzz will fake a vert feature and lookup and hb_ot_layout_lookup_collect_glyphs() would work on it (is this the case for fallback Arabic shaping?).

[behdad]

Would be easier if HB just does the simple thing and LibreOffice doesn't try to be smarter.

[khaledhosny]

But then people will scream REGRESSIONS! to me because that is kinda what pre-HarfBuzz code did (it was parsing the GSUB table in its own).

[behdad]

Ok, not clear what to do anymore. Let's get back to this some other time.

[KrasnayaPloshchad]

When a proportional font as Tangut N4694 used in vertical writing, but does not include such feature for glyph mapped in Tangut codepoints, I think these glyphs should be sightly centered for better rendering.

[KrasnayaPloshchad]

When a proportional font as Tangut N4694 used in vertical writing, but does not include such feature for glyph mapped in Tangut codepoints, I think these glyphs should be sightly centered for better rendering.

According to TDF bugzilla, such glyphs should be allowed to well aligned with strikethrough in vertical layout.

https://bugs.documentfoundation.org/show_bug.cgi?id=105650

[behdad]

@khaledhosny Can you summarize proposed change to HB?

[khaledhosny]

I think this should be closed for now, seems better handled by applications since there are at least two incompatible ways to do it.

[behdad]

I hope we can converge onto one. I think this is in scope for harfbuzz.

[behdad]

Now I realize that if HarfBuzz implemented the fallback vertical shaping, my solution will rotate the fallback presentation forms glyphs.

Not if you break run around those and shape them for dir=LTR and rotate.

Well unless HarfBuzz will fake a vert feature and lookup and hb_ot_layout_lookup_collect_glyphs() would work on it

(is this the case for fallback Arabic shaping?).

No. Same thing for character-level mirroring.

[khaledhosny]

What I’m currently doing is to segment the text based on vertical orientation property; U, Tu and Tr go into the same run and are shaped with TTB direction, and R is shaped LTR or RTL based on bidi level. Then after shaping if the character has Tr vertical orientation and the glyph does not seem to be a vertical alternate (based on vert coverage) I rotate it.

If I shaped Tr glyphs separately with LTR direction, then I’ll not use vertical alternates in fonts that provide it, and even if HarfBuzz implemented fallback vertical shaping it will not be used since the direction is not TTB.

[behdad]

So you rotate a glyph mid-shape-results. Ouch!!

What I meant was to make vert-fallback an input to itemizer, ie only shape horiz-LTR those that you are going to rotate.

[khaledhosny]

Yes. What complicates things is that I want to use the rotated glyphs that the font might have, so the decision to rotate has to be taken after shaping.

[behdad]

Yes. What complicates things is that I want to use the rotated glyphs that the font might have, so the decision to rotate has to be taken after shaping.

What if char A's unrotated glyph is same as char B's rotated glyph? I would have guessed you check whether the nominal glyph for a char is in the "input-set" of the vert feature, not output... That test can happen before shaping.

[khaledhosny]

What if char A's unrotated glyph is same as char B's rotated glyph?

I thought about this initially then decided it does not really matter, if the glyph is considered rotated in the some context then I probably do not want to rotate it any way. But I admit it does not sound very convincing :)

I would have guessed you check whether the nominal glyph for a char is in the "input-set" of the vert feature, not output... That test can happen before shaping.

That sounds doable. I need to call hb_font_get_glyph() myself for Tr chars, and I now need to worry about variation selectors, oh well. :)

[khaledhosny]

I just did as suggested in LibreOffice and it seems to work fine so far. So I think character-level fallback at HarfBuzz shouldn't interfere with what I’m doing.

[behdad]

Jonathan and I discussed this. We like to implement what Firefox does in HarfBuzz itself. Ie. if vert lookup is missing do character-based fallback.

[behdad]

Ooh. I don't remember what this is about. Need to read again. But yeah let's do it and close.

[behdad]

Okay Jonathan and I looked into this again now. Implementing it. We decided right place is to put this logic in hb_ot_mirror_chars and rename that to hb_ot_rotate_chars. :)

[drott]

This makes some vertical orientation sideways/upright tests fail on Mac OS 10.12 and below.

Looking at @khaledhosny's commits and @behdad's #355 (comment), does this mean, I need to make the OrientationIterator in Chromium which decides whether a run is rotated LTR or upright hb_font aware to check whether vertical alternates exist?

That'll complicate some things in Blink: Currently, orientation segmentation happens pre-shaping and font, independent - I only break the runs further after shaping due to fallback, not due to orientation segmentation.

So would follow from this change, that I need to move orientation segmentation down to after shaping with the benefit with getting the rotate glyphs from the font if it has it, rather than always rotating upfront?

[drott]

@kojiishi

[drott]

https://bugs.chromium.org/p/chromium/issues/detail?id=1040017#c8 <- more discussion in Chromium bug. I think in the end in Chromium this only mapped to problems with Hiragino and was solved by the fix for #2124 - so I think you can ignore my comment above.

[behdad]

Looking at @khaledhosny's commits and @behdad's #355 (comment), does this mean, I need to make the OrientationIterator in Chromium which decides whether a run is rotated LTR or upright hb_font aware to check whether vertical alternates exist?

That'll complicate some things in Blink: Currently, orientation segmentation happens pre-shaping and font, independent - I only break the runs further after shaping due to fallback, not due to orientation segmentation.

So would follow from this change, that I need to move orientation segmentation down to after shaping with the benefit with getting the rotate glyphs from the font if it has it, rather than always rotating upfront?

So if you read through https://bugzilla.mozilla.org/show_bug.cgi?id=1164835
it looks like the CSS Writing Systems as well as UTR 50 say for characters in class Tr you want to see if font rotates them, and if not you rotate them. That, if you try it exactly, does mean that you need to do your orientation segmentation tightly closed to shaping. Or rather, do it like font-fallback on result of shaping... Or do as Khaled did, to look inside the font.

But I suggest you forget that, and just treat Tr same as Tu and let HarfBuzz try to rotate those. I don't think you should try harder on the Chrome side.

[kojiishi]

it looks like the CSS Writing Systems as well as UTR 50 say for characters in class Tr you want to see if font rotates them, and if not you rotate them. That, if you try it exactly, does mean that you need to do your orientation segmentation tightly closed to shaping. Or rather, do it like font-fallback on result of shaping... Or do as Khaled did, to look inside the font.

Writing Modes defines it a bit differently, sorry if the current text reads so to you.

UTR 50 is for wide variety of applications and font technologies, so yes, it allows apps/fonts doing it.

CSS Writing Modes is about specific implementations, with interoperability as its goal. In interpreting what to do for Tr, we explicitly decide it not to require to look into fonts beforehand. This is part because to simplify implementation, but also because, while rendering engines can know whether a glyph has a vertical variant or not, it does not mean whether a glyph is upright or rotated. Some fonts has rotated glyphs in vert glyphs, so a glyph with vertical variant may or may not be rotated visually.

We investigated a lot of major fonts available, and unfortunately concluded that they're not interoperable enough to make visual orientations perfectly interoperable. With that, we set the goal of CSS Writing Modes as, browsers providing interoperable implementations (orientations) can encourage fonts to match UTR 50, and it will make orientation interoperable anywhere in future, but making visual orientations interoperable for non-UTR 50 fonts is not a goal of CSS Writing Modes.

[drott]

Thanks for sharing, Koji, interesting to read.