[MPEG-OTSPEC] Vertical Writing: Character Orientations are Sometimes Uncontrollable

Fri Aug 7 07:22:27 CEST 2020

Makoto,

>> Therefore we need to define and implement a mechanism that allows layout engines to resolve a glyph’s rotation property based on both a predefined dataset *and* the current font’s overriding.
> 
> I am very interested in your suggestion and hope to hear more.

A common pattern we use in complex text shaping (most for Indic scripts’ glyph reordering) to enable font-dependent (thus allowing fonts to override some default behavior) shaping/layout is that, we specify the shaping/layout engine should extract glyph properties from the lookups registered to certain OTL features before starting doing the shaping/layout.

For example, we could specify that, no matter what default rotation property (upright or rotated) the layout engine thinks a glyph has, it must first examine the OTL vert and vrtr features, and all glyphs resulted in vert must be kept upright, while all glyphs resulted in vrtr must be rotated. In this way, fonts get an opportunity to resolve incompatibility by explicitly declaring which glyphs are expected to be upright or rotated.

> I heard that CSS border does not work for characters containing accents 
> when they appear in vertically written text.  This is not surprising.

Um, not clear what this means…

Best,
梁海 Liang Hai
https://lianghai.github.io

> On Aug 6, 2020, at 21:27, MURATA Makoto <eb2m-mrt at asahi-net.or.jp> wrote:
> 
> Ken,
> 
> 2020年8月6日(木) 22:11 Ken Lunde <ken.lunde at gmail.com <mailto:ken.lunde at gmail.com>>:
> Murata-san,
> 
> The use of "compliance" in the context of the Source Han Sans (and Source Han Serif and Source Han Mono) ReadMe PDF is in direct reference to explicitly *not* including pre-rotated forms of non–full-width glyphs and excluding substitutions for arrows and arrow-like characters, which is clearly stated:
> 
> > UAX #50 Compliance
> > Source Han Sans is one of the first font implementations that is compliant with UAX #50 (Unicode Vertical Text Layout). Only the substitutions in the 'vert' GSUB feature are expected to be used, and the 'vrt2' GSUB feature, which is a subset of the 'vert' GSUB feature, is included only because some environments, such as Windows and some Microsoft applications, require it to be present. In particular, pre-rotated non–full-width glyphs have been excluded from the 'vrt2' GSUB feature, and substitutions for arrows and arrow-like characters have also been excluded from both GSUB features.
> 
> 
> Thanks for your clarification. 
> 
> Ten Mincho (貂明朝) is another contemporary typeface whose fonts are UAX #50 compliant in the same sense:
> 
> https://blogs.adobe.com/CCJKType/2018/11/ten-mincho-redux.html <https://blogs.adobe.com/CCJKType/2018/11/ten-mincho-redux.html>
> 
> As Liang was suggesting, the UAX #50 property values are not absolutes -- and cannot be -- and implementations are free to tailor as necessary. A good example can again be found in the Source Han typefaces: all of the full-size kana include a vertical form whose shape is subtly different from the default (horizontal) form. The vo property value for these characters is "U," but the fonts are tailored in such a way that they are virtually "Tu" in that they are transforming. In other words, fonts are allowed to transform.
> 
> 
> I remember that the original intent of the CSS WG was to 
> ensure conformant CSS user agents to provide the same 
> text orientation.  This is exactly what Japanese publishers 
> hope to have.  Fidelity is more important for users.  But 
> it is not there.
>  
> And yes, I agree that the standard 'vert' GSUB feature definition of Adobe-Japan1, which is what you mean when you state "AJ1 font template" in your slide deck, would benefit from tweaking. The difficulty, of course, is propagating the change to the large number of installed fonts, which tend to be among the most enduring pieces of digital code.
> 
> It appears that every Japanese vendor faithfully follows the AJ1 font template.  
> I do not think that changing them in an incompatible way is possible.
> 
> With regard to changing the vo property of U+FF1B ； FULLWIDTH SEMICOLON from "Tr" to "Tu" on page 14 of your slide deck, please, please, please submit the suggestion here:
> 
> https://corp.unicode.org/reporting.html <https://corp.unicode.org/reporting.html>
> 
> I have been trying to convince the other co-editor of UAX #50 to make this change. Having another voice would be very helpful.
> 
> Sure.  Let me try. 
> 
> Regards,
> Makoto
>  
> 
> Regards...
> 
> -- Ken
> 
> > On Aug 6, 2020, at 05:10, MURATA Makoto <eb2m-mrt at asahi-net.or.jp <mailto:eb2m-mrt at asahi-net.or.jp>> wrote:
> > 
> > Liang,
> > 
> > 2020年8月6日(木) 19:12 梁海 Liang Hai <lianghai at gmail.com <mailto:lianghai at gmail.com>>:
> > The “compliance” talked about in the slides sounds a bit misguided.
> > 
> > It may well be.  But this term was introduced by Source Han Sans.
> > 
> > https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf <https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf>
> > 
> > This document suggests that all other fonts are NOT 
> > UAX#50 compliant.
> > 
> > 
> > The behavior specified by UAX #50 is a decent low-level default at most, and can’t address all the use cases. Therefore fonts naturally need to be diverse and address the flexibility required by typography.
> > 
> > The architectural problem is that, layout engines assume a predefined rotation property (based on UAX #50 or not) for characters, and there’s no reliable way to override that. The boundaries between rotated and upright runs even makes OTL a non-starter.
> > 
> > Certainly, nothing is reliable.  This is unfortunately the case right now. 
> > 
> > Therefore we need to define and implement a mechanism that allows layout engines to resolve a glyph’s rotation property based on both a predefined dataset *and* the current font’s overriding.
> > 
> > I am very interested in your suggestion and hope to hear more.
> > 
> > I heard that CSS border does not work for characters containing accents 
> > when they appear in vertically written text.  This is not surprising.
> > 
> > Regards,
> > Makoto
> > 
> > 
> > Best,
> > 梁海 Liang Hai
> > https://lianghai.github.io <https://lianghai.github.io/>
> > 
> >> On Aug 6, 2020, at 07:37, MURATA Makoto <eb2m-mrt at asahi-net.or.jp <mailto:eb2m-mrt at asahi-net.or.jp>> wrote:
> >> 
> >> Folks,
> >> 
> >> This presentation explains typical problems around interactions 
> >> of fonts and vertical writing.
> >> 
> >> https://1drv.ms/p/s!An5Z79wj5AZBgsdN2pd2XmS08WslZA?e=UM5O6K <https://1drv.ms/p/s!An5Z79wj5AZBgsdN2pd2XmS08WslZA?e=UM5O6K>
> >> 
> >> Japanese publishers are forced to use rasterized text, which hampers 
> >> accessibility.  I hope that the activities planned here help to make 
> >> things better.
> >> 
> >> -- 
> >> Regards,
> >> Makoto
> >> _______________________________________________
> >> mpeg-otspec mailing list
> >> mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at>
> >> https://lists.aau.at/mailman/listinfo/mpeg-otspec <https://lists.aau.at/mailman/listinfo/mpeg-otspec>
> > 
> > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at>
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec <https://lists.aau.at/mailman/listinfo/mpeg-otspec>
> > 
> > 
> > -- 
> > Regards,
> > Makoto
> > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at>
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec <https://lists.aau.at/mailman/listinfo/mpeg-otspec>
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at>
> https://lists.aau.at/mailman/listinfo/mpeg-otspec <https://lists.aau.at/mailman/listinfo/mpeg-otspec>
> 
> 
> -- 
> Regards,
> Makoto
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at>
> https://lists.aau.at/mailman/listinfo/mpeg-otspec <https://lists.aau.at/mailman/listinfo/mpeg-otspec>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200807/d203348b/attachment-0001.html>