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

[MURATA Makoto]

Ken,

2020年8月6日(木) 22:11 Ken Lunde <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
>
> 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
>
> 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>
> 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
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>


-- 
Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200806/d274471b/attachment-0001.html>