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

[Levantovsky, Vladimir]

Murata-san,

You wrote:
As far as I know, nobody in the Japanese font
industry is interested in updating existing
fonts so that they comply with UAX#50.  This
is understandable, since users frown on
such changes.

So, for the sake of an argument, let’s hypothesize that instead of updating some of the existing fonts to support new version of UAX#50-compliant ‘vert’ feature implementation, we decided to switch to a new [yet to be standardized] feature “that specifically imposes the rules (and may be fallback to 'vert')”.
How do we expect this feature be implemented? Won’t we need ALL implementations and ALL fonts to be updated for the new feature to work? If users frown upon any changes in existing Japanese fonts, why do you believe defining a new feature would make a difference?

Thank you,
Vladimir


From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of MURATA Makoto
Sent: Tuesday, August 11, 2020 5:08 PM
To: mpeg-otspec at lists.aau.at
Subject: Re: [MPEG-OTSPEC] Vertical Writing: Character Orientations are Sometimes Uncontrollable

I agree with Eric.

In the Internet world, authors do not know which application
and which font is used for rendering their contents, but
they still would like to ensure the same character orientation
everywhere.  I suppose that the same scenario probably
applies to other features for other languages, and
that more and more problems will arise.

David wrote:
> * behavior should only be embedded in fonts if it is expected to vary between fonts; constant properties of characters that are independent of fonts should be expressed once
> * it should be possible (e.g. by user-side style-sheet) to substitute a font (from the one the author expected or previewed with) and still get correct layout

This is thoughtful advice.  But OpenType allows
font developers to create their own glyph set,
specify a cmap,'vert' and other features.  Thus,
interoperability cannot be easily achieved.  A
well-know glyph set (such as AJ1) is a big help,
but the standard 'vert' GSUB feature
definition of Adobe-Japan1 is not compliant
with UAX #50 (Unicode Vertical Text Layout).

Eric wrote:
>   I can only see two solutions, after having
> picked the rules: 1) we fix the fonts that
> do not follow the rules or 2) we switch to a
> new feature that specifically imposes the
> rules (and may be fallback to 'vert').  I
> suspect that 1) is not an option.
David wrote:
> Which leads me to suspect that (2) is better than (1).

As far as I know, nobody in the Japanese font
industry is interested in updating existing
fonts so that they comply with UAX#50.  This
is understandable, since users frown on
such changes.

As I see it, font developers often say that
the rest is up to application programmers.
Poor application programmers are thus
forced to implement ad-hoc behaviors
depending on the character and
also depending on the font used.

For example, Firefox implements
such an ad-hoc behavior for wavy dash.

> Handle fallback (rotated) rendering of characters with Vertical_Orientation=Tr
> when the font does not support them via 'vert', nor is there a vertical presentation
> form encoded in Unicode.

This is copied from
https://bugzilla.mozilla.org/show_bug.cgi?id=1431305<https://protect-us.mimecast.com/s/OPiOCXD0wrhXQZzxi6gfj1>

This behavior is allowed by CSS Writing Modes.

https://www.w3.org/TR/css-writing-modes-3/#typeset-upright<https://protect-us.mimecast.com/s/wYQCCYEnxytL7X4zCG401e>
> Typographic character units which are classified as Tr or Tu in [UAX50] are expected
> to have alternate glyphs or positioning for typesetting upright in vertical text.
> In the case of Tr characters, if such vertical alternate glyphs are missing from the
> font, the UA may wish to [RFC6919] (but is not expected to) synthesize the missing glyphs
> by typesetting them sideways etc.

Forefox wishes to synthesize the missing glyphs
by typesetting them sideways etc but not for other
characters.  The proliferation of such a workaround
might make things even worse eventually.

Forefox also implements an ad-hoc behavior for double vertical
line: it ignores the vert feature, although CSS Writing
Modes clearly specifies that " (E.g. the OpenType vert feature must
be enabled.) "

Regards,
Makoto

2020年8月8日(土) 11:41 Eric Muller <eric.muller at efele.net<mailto:eric.muller at efele.net>>:
On 8/6/2020 3:11 AM, 梁海 Liang Hai wrote:
> 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 also disagree with the second sentence as a consequence of the first.
UAX50 is not in control of the orientation. The author, via markup, is
in control (at least, wants to be; that's implicit in Murata-san's
presentation). UAX50 is there only to make the life of the author
simpler, by minimizing markup. You can think of running a transformation
on documents that inject explicit markup, according to UAX50, wherever
the author did not explicitly put it. That document would have a precise
meaning regardless of UAX50.

The way I see the current situation is that we have many fonts that
predate the need for the author to control the orientation regardless of
the font, rather than the author reacting to the font. The later is
acceptable in the print world, where layout is done at "factory" time,
the author (in a broad sense) can see exactly what the reader will see,
and can adjust his document to the font. It is problematic in the
ebook/web world where the layout is done at "reading" time, with pieces
or behaviors that the author does not always control (in particular
fonts). In that world, we need fonts (and layout engines) that respect
precisely the orientation chosen by the author (and of course document
formats that let him or her express the desired orientation)

The link between layout engines and fonts is the 'vert' feature. So what
Murata-san wants is for the 'vert' feature to behave according to some
known fixed rules (of course, the UAX50 rules are an obvious choice, but
by no means necessary), rather than the current situation where MS
Mincho does it one way and Meiryo does it another way. I can only see
two solutions, after having picked the rules: 1) we fix the fonts that
do not follow the rules or 2) we switch to a new feature that
specifically imposes the rules (and may be fallback to 'vert') . I
suspect that 1) is not an option.

Eric.


_______________________________________________
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://protect-us.mimecast.com/s/QnOnCZ6oyzh56Yp3iKk3-0>


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