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

[MURATA Makoto]

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

This behavior is allowed by CSS Writing Modes.

https://www.w3.org/TR/css-writing-modes-3/#typeset-upright
> 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>:

> 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
> 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/20200812/04a7ea71/attachment.html>