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

[MURATA Makoto]

Liang,



2020年8月16日(日) 3:28 梁海 Liang Hai <lianghai at gmail.com>:

> Eric,
>
> >> 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.
> >
> > I disagree with the second sentence, when interpreted anywhere close to
> "fonts can do anything". We need fonts to do their part. If a U+0041 A
> LATIN CAPITAL LETTER A is displayed by a "B", we can clearly blame the font
> and declare it useless for rendering text. Similarly if "MANZANITA" is
> displayed at "MAZNAZITA" by the font deciding to rotate N and Z, we are in
> trouble.
>
> I’m not sure why you felt the need to interpret the sentence in this way.
> But it feels like you wasn’t aware of the complete context of the issue.
> I’m not gonna even talk about UAX #50’s inherent inability of addressing
> different locale’s different preferences about certain characters’
> orientation—now let’s just talk about compatibility.
>
> Implementations are naturally incompatible. Adoption of UAX #50 varies.
> UAX #50 itself isn’t stable either. New characters get encoded. Old and new
> products coexist. It’s pretty clear you can’t assume all target
> environments of a font to have consistency of glyph orientation.


So, are you saying fidelity of text orientations is impossible?

Publishers of EPUB publications strongly require fidelity.
They request implementors to provide fidelity.  Kadokawa
(a big publisher in Japan) created a list of behaviors of
several EPUB readers for code points used in Japan.
UAX#50 should be stable with the exception of newly
added characters.  Non-conformant implemenations
are decreasing and will be avoided by the market.

If fidelity is nor provided, publishers use rasterized
text, which is not at all accessible.  This is really
a shame.

Regards,
Makoto




>
> Now, U+00A9 © COPYRIGHT SIGN is rotated in Word but upright in Chrome.
> This is just two products. How do I resolve this incompatibility issue? Is
> this markup’s responsibility?
>
> Best,
> 梁海 Liang Hai
> https://lianghai.github.io
>
> _______________________________________________
> 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/20200816/826369ab/attachment.html>