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:48:26 +0900
Message-ID: <CALvn5EBdHd4HZ4BTQdGDcuMx6pJuMzejU2SwDCo4Asuuspfeqw@mail.gmail.com>
To: www-archive@w3.org
---------- Forwarded message ---------
From: Taro Yamamoto <tyamamot@adobe.com>
Date: 2019年12月9日(月) 17:14
Subject: Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?
To: fantasai <fantasai@inkedblade.net>, MURATA Makoto <
eb2m-mrt@asahi-net.or.jp>, Nat McCully <nmccully@adobe.com>
Cc: Florian Rivoal <florian@rivoal.net>

2019/12/09 15:36 に、"fantasai" <fantasai@inkedblade.net> を書き込みました:
    The 'vert' feature should not, in general, be controlling the rotation
    glyphs other than Tr glyphs. It should provide alternates for upright
    typesetting, for when the application indicates to the font that this
run of
    text will be upright.

    If a font is compatible with application software that can take any
glyph and
    override its orientation to be upright or sideways, then it is
    compatible with CSS Writing Modes and UAX50.

Yes, I agree. So, if the 'vert' features in fonts were changed or
unchanged, if it did not meet the expectation by applications, it would
produce problems, and if the applications' handling of vertical postures
were changed or unchanged, if it contradicted the behavior assumed by the
fonts, it would produce problems. So, it is not sufficient to have each
font or application pretend to conform to UAX50, self-righteously without

    This is an example of UAX50 having a different default orientation than
such a
    page layout application software. This is why such software, as Nat
    cannot "upgrade" itself to match UAX50, but has to offer it as an
opt-in option.

    It is not an example of an incompatibility of the font with UAX50.

    UAX50 is only a table of defaults, similar to the one in InDesign that
    whether the default orientation of a glyph should be upright or
sideways, but
    with potentially some different values.

Yes, I agree also with this.
One example that was discussed at the last meeting with Murata--san: U+2192
RIGHTWARDS ARROW, whose vertical posture is defined to be 'R' by UAX50, but
has been traditionally been included in the 'vert' table of fonts based on
the Adobe-Japan1-x Character Collection (glyph set) since the late 1980s.
According to Nat, InDesign assumes its vertical posture to be 'Tr', so
InDesign lets the 'vert' do the "pseudo-rotation" for the corresponding
glyph without any scruple.  There are very many similar cases, where glyphs
corresponding to the characters whose vertical postures are defined to be
'R' by UAX50 are assumed to have the 'Tr' vertical posture, and as a
result, our fonts have them in the 'vert' features to do the
"pseudo-rotation". At this point, my guess may be wrong, but I have the
idea that without the assumption, if these characters had not been assumed
to have the 'R' vertical posture, as expected by UAX50 today, it would have
not been possible for anyone to guarantee that the glyphs corresponding to
these characters could have been rotated correctly at the very center of
the Japanese EM square type body. There is the distinction here between
Japanese glyphs and Western glyphs to be detected beforehand.

However, as far as the 'vert' features are concerned, which are in font,
for any font developers, it is self-explanatory whether a font is for
Japanese or Western languages/scripts. So, by having the 'vert' features do
the "pseudo-rotation", applications seem to have been free from the
responsibility of rotating Japanese glyphs at the center of their EM square
type bodies. Whatever type of glyphs, Japanese full-width characters or
Western proportional glyphs, as far as applications position them correctly
by rotating and shifting them, understanding how they should be positioned
in Japanese vertical lines, it is not necessary to have those 'R' glyphs in
the 'vert' features, but it is possible to have applications really rotate
and shift them. But I guess it was impossible to assume all applications
really could do it in those days. But is it possible to guarantee that they
do it rightly at the end of 2019?



Received on Thursday, 12 December 2019 04:49:08 UTC

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