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

---------- Forwarded message ---------
From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: 2019年12月1日(日) 13:28
Subject: Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?
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>


It appears that some fonts specify the vert feature in a
way inconsistent with CSS WM and UAX#50.  It becomes
impossible to use the glyph as specified in the Unicode
chart, since the vert feature always provide a different
glyph.  I learned this from Murakami-san.

They are listed in Clause 4 of my document
<https://1drv.ms/w/s!An5Z79wj5AZBgrg5Ou3YePMMvDYKXg?e=Xip2Wq>.  I intend to
start
discussions in Japanese 文字情報推進協議会 and the
upcoming JWG for OpenType.

Regards,
Makoto

2019年11月25日(月) 20:15 MURATA Makoto <eb2m-mrt@asahi-net.or.jp>:

> Nat,
>
> I am wondering what is the real difference between
> CSS Writing Modes and InDesign.
>
> >  our applications do not rely on font features to determine orientation
>
> The same in CSS Writing Modes.  The orientation is defined by
> the text-orientation property
> <https://www.w3.org/TR/css-writing-modes-3/#text-orientation>.  If the
> value is upright or sideways,
> it specifies the orientation.  If the value is mixed, UAX#50
> determines the orientation.  OpenType features are
> not used.
>
> > such lookups are designed ... allow the application to make
> substitutions according to its own rules and needs (or that of the user)
>
> The same in CSS Writing Modes.  This is clearly stated in
> the note in the subsection "upright typesetting"
> <https://www.w3.org/TR/css-writing-modes-3/#typeset-upright>.  The use
> of "vert" is mandated.
>
> Regards,
> Makoto
>
> 2019年11月25日(月) 14:23 Nat McCully <nmccully@adobe.com>:
>
>> 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
>


-- 
Regards,
Makoto


-- 
Regards,
Makoto