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

[Ken Lunde]

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.


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

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.

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.

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

I have been trying to convince the other co-editor of UAX #50 to make this change. Having another voice would be very helpful.

Regards...

-- Ken

> On Aug 6, 2020, at 05:10, MURATA Makoto <eb2m-mrt at asahi-net.or.jp> wrote:
> 
> Liang,
> 
> 2020年8月6日(木) 19:12 梁海 Liang Hai <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
> 
> 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
> 
>> On Aug 6, 2020, at 07:37, MURATA Makoto <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
>> 
>> 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
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
> 
> -- 
> Regards,
> Makoto
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec