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

MURATA Makoto eb2m-mrt at asahi-net.or.jp
Thu Aug 6 14:10:30 CEST 2020


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#59 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200806/84c11469/attachment.html>


More information about the mpeg-otspec mailing list