W3C home > Mailing lists > Public > www-archive@w3.org > December 2019

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

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Thu, 12 Dec 2019 13:47:23 +0900
Message-ID: <CALvn5EC3CKdjmQGzd+8+qM73KcYedxGWYnhqXzP5RqTsujHPzg@mail.gmail.com>
To: www-archive@w3.org
---------- Forwarded message ---------
From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: 2019年11月25日(月) 20:15
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>


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
Received on Thursday, 12 December 2019 04:48:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:17 UTC