Fwd: UAX#50 conformance: Is it possible to update existing fonts without causing damage to existing non-CSS applications?

---------- Forwarded message ---------
From: Nat McCully <nmccully@adobe.com>
Date: 2019年11月25日(月) 14:23
Subject: Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?
To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Cc: Taro Yamamoto <tyamamot@adobe.com>, Florian Rivoal <florian@rivoal.net>,
fantasai <fantasai@inkedblade.net>


Hi Murata-san

Before making a recommendation for fonts and CSS features related to font
features, I think we need to be aware of some of the considerations of the
app developer, so to that end, allow me to explain how InDesign does it
today:

Because Unicode unified certain glyphs that were distinct in SJIS encoding,
which Unicode codepoints get rotated and which are upright can change
depending on the font. However, OTF features alone are not used to
determine orientation—it was thought too expensive to query whether a given
vertical orientation feature (like 'vert' or 'vrt2') would result in a
glyph change, for every character. Instead, prior to running GSUB features,
the vertical runs are broken up into like orientations ahead of time, based
solely on Unicode tables and knowledge of font script (and prevailing
SJIS/proportional glyph designs in such font scripts). At this time,
neither InDesign nor Illustrator use UAX#50; they use their own tables
tuned to the known fonts at the time (20 years ago). To improve things, I
plan to make a new feature to use UAX#50, but due to the significant risk
of reflow of existing documents (glyphs changing orientation, user
workarounds no longer needed, etc), you can imagine how complicated
introducing the new behavior will be. In fact, unless a significant number
of users ask for such an improvement, it cannot happen. I believe, however,
that it must happen to improve the situation you are talking about.
Once the vertical orientation is determined for a given run, then 'vert' is
added to the active OTF features in the runs that are upright, and final
glyphs are retrieved, measured, etc., for layout. You cannot just add
'vert' to everything for it has an effect on punctuation and on Latin
glyphs, so it is definitely only usable on known upright glyphs so their
correct vertical variants can be used.
Adobe does not use 'vrt2', but instead rotates the runs according to the
above. I understand Apple CoreText uses it however (and not 'vert'?).
I am not familiar with 'vrtr' but I do not think we use it either (after my
time).

My point is that as of now, our applications do not rely on font features
to determine orientation because GSUB lookups are not fast enough (I
haven't tested lately, though), and such lookups are designed not to tell
an application what to do, but allow the application to make substitutions
according to its own rules and needs (or that of the user). The app and
user determine orientation, then tell the font what to do. Admittedly, the
font designer can mess this up by changing SJIS default glyphs (like smart
quotes) into proportional Roman ones, just as happened years ago with
Hiragino. That caused us to have to make a fix in our vertical tables to
prefer Hiragino's proportional smart quotes (sideways in vertical) to
legacy Japanese fonts that used SJIS designed full-width smart quotes
(upright in vertical) as the default. Also, if a font designer uses 'vert'
assuming they can change orientation with it, they will fail in such a
system described above. In our reading of the feature, it does not change
orientation, it merely substitutes the correct vertical glyph on an already
upright Unicode codepoint.

--Nat
------------------------------
*From:* MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
*Sent:* Sunday, November 24, 2019 20:35
*To:* Nat McCully <nmccully@adobe.com>
*Cc:* Taro Yamamoto <tyamamot@adobe.com>; Florian Rivoal <florian@rivoal.net>;
fantasai <fantasai@inkedblade.net>; MURATA Makoto (FAMILY Given) <
eb2m-mrt@asahi-net.or.jp>
*Subject:* UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?

Nat,

I am wondering what is needed from font people
(including the upcoming Joint Working Group of SC34
and SC29 about OpenType) about vertical writing.

First, here is my understanding of the issue.

Interactions between fonts and applications have
been vague historically.  They are not based on any
written contracts.  Font developers implement
OpenType features without knowing whether they are
used by applications; application programmers
implement text rendering without knowing whether
fonts provide relevant OpenType features.

Meanwhile, recent OWP requires fidelity among
different web browsers.  In other words, users
expect that different web browsers on different
platforms provide reasonably similar results.  Such
fidelity is hampered by vague interactions of
fonts and applications, however.

In particular, the Japanese publishing industry
requires fidelity among different EPUB readers as
far as character rotation in vertical writing is
concerned.  If enough fidelity is not available,
Japanese publishers dare to use character-like
images.

To provide more fidelity, CSS specifications start
to say more about fonts.  In particular, CSS
Writing Modes require that the vert feature of
OpenType must be enabled for upright typesetting.
CSS Writing Modes further mentions the vrtr feature
for sideways typesetting.  The choice of upright
and sideways by default is done by UAX#50 rather
than the vrt2 feature.  I also think that we have
to move away from vague interactions and establish
contracts between applications and fonts.

But OpenType fonts equipped with the vert feature
already exist.  In my understanding, such fonts do
not necessarily do what CSS Writing Modes expect.
CSS people hope that existing OpenType fonts are
updated as required by CSS Writing Modes.

I have discussed with Yamamoto-san of Adobe.  He
strongly feels that it is impossible to update
existing fonts without causing damage to existing
non-CSS applications.  I assume that his opinion is
based on discussions internal to Adobe.

If existing fonts cannot be updated as required by
CSS Writing Modes and UTS#50, what should we do?
I am wondering if we should introduce yet another
feature (maybe "cssVert").

Regards,
Makoto (promoting the JWG for OpenType from the SC34 side)


-- 
Regards,
Makoto