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年12月10日(火) 11:03
Subject: Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?
To: Taro Yamamoto <tyamamot@adobe.com>, fantasai <fantasai@inkedblade.net>
Cc: Florian Rivoal <florian@rivoal.net>, MURATA Makoto <
eb2m-mrt@asahi-net.or.jp>


I think that one could argue that UAX50 should not consider any
historically SJIS character as "R", without risking side-effects of
incorrect rotation or other Latin-mode typographic layout ("R" usually
means lay the glyph out as you would Latin glyphs).

This is why InDesign makes all SJIS characters (aka full-width codepoints
in J fonts) as upright in vertical (not "R"), and the font designer is in
charge of any pseudo-rotation via 'vert'.

While InDesign would most likely rotate the "R" full-width glyphs correctly
on their centers, I could see situations where the dominant Latin baseline
or other Latin metrics would be assumed, or the underline position, or
other Latin-mode behaviors, simply because "R" means "embed Latin
horizontal behaviors into this part of the vertical line" currently.

So, although it violates some concept of Unicode purity across scripts, I
would not be opposed to changing UAX50 full-width codepoints that came from
SJIS, to be "Tr" and not "R".

--Nat

On 12/9/19, 5:49 PM, "Taro Yamamoto" <tyamamot@adobe.com> wrote:

    2019/12/10 0:37 に、"fantasai" <fantasai@inkedblade.net> を書き込みました:
        On 12/9/19 3:14 AM, Taro Yamamoto wrote:
        >
        > 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 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 this false assumption, if these characters had 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.

    (Sorry for some typos and wrong English descriptions, I made
corrections directly to the previous message of mine that you quoted above).

        Ah, this is the tricky case. A 'vert' feature which implements
Tr-style
        rotated alternate instead of upright-style alternate for some glyph
would be
        incompatible with the intention of UAX50/CSSWM for that glyph.

        I wonder if there are many examples other than arrows?

    There are very many: equal sign, some quotes, degree, other arrows,
dashes and rules, etc.

        We think there are definitely glyphs for which a rotated
presentation needs an
        alternate glyph rather than a simple rotation by the application.
But this is
        why the 'vrtr' feature was added to OpenType. For such characters,
it is
        intended for the application to rotate them, and the font to
provide a 'vrtr'
        alternate for vertical presentation of a rotated glyph.

    Yes, I know this discussion, and it was first introduced in the
following article:
    https://blogs.adobe.com/CCJKType/2013/08/tale-of-three-features.html

        The CSS Writing Modes system uses the combination of this 'vrtr'
feature, the
        application’s ability to set any character upright or not upright
(defaulting
        to UAX50), and the 'vert' feature as intended for truly upright
typesetting of
        each character (excepting those such as brackets for which an
upright
        presentation would be nonsensical, which are marked as Tr in
UAX50). This
        should give authors, applications, and fonts together the ability
to typeset
        text perfectly in each case,

    So, to say briefly, it follows that all 'Tr' glyphs are to be included
in the 'vrtr' feature, and all 'Tu' glyphs are to be in the 'vert' feature,
and all 'R' glyphs that have traditionally been included in the 'vert'
features are to be excluded from the 'vert' feature (according to your
UAX50-conforming scheme), doesn't it?

        The concern for compatibility of fonts with such a system then
seems to be
        whether fonts have 'vert' alternates that rotate characters which,
in a fully
        upright typesetting style, could be upright. For example, the case
of arrows
        you discuss above. In such cases, there is no way to set that glyph
upright
        except maybe to disable the 'vert' feature.

    If we call the abovementioned "UAX50 conforming" version of the 'vert'
feature as "UAX50vert" only for this discussion here, UAX50vert won't
include any R glyphs. Related to what I wrote in my previous message, I'm
still a little concerned about the Japanese-typographic correctness and
precision of the rotation that is to be done by applications without making
use of the 'vert'-based glyph substitution (which may be called
"pseudo-rotation").

    For example, U+2015 HORIZONTAL BAR has been used widely as an EM-dash
for Japanese, which is expected to be positioned at the mean height of, and
centered at, the Japanese EM type body, because U+2014 EM DASH has been
used for proportional Latin characters, and its height of the bar of the
glyph included in fonts is far below the center line of the EM square body,
as it must match the height of the lower-case characters (x-height),
positioned slightly above the mean height between the x-height and the
baseline (y = 0). Our Adobe-Japan1-x-baesd fonts include the glyph for the
U+2015 HORIZONTAL BAR in the 'vert' feature with the "pseudo-rotated"
vertical glyph.

    However, according to UAX50, U+2015 HORIZONTAL BAR has the 'R' vertical
posture. So, it will not be included in the UAX50vert feature supporting
UAX50. As the vertical posture is not 'Tr', it will not be in the 'vrtr'
table as well. I guess applications are expected to rotate it when used in
a vertical line. As far as Japanese vertical lines are concerned, whatever
glyph is used (proportional Latin glyphs or full-width Japanese glyphs), as
far as applications apply the rotation at the center of the square EM type
body precisely, there will not be a problem.

    In addition to the incompatibility of existing Japanese fonts with
UAX50 due to their inclusion of glyphs whose UAX50 vertical posture is R in
their 'vert' feature, another type of incompatibility is due to their
treating glyphs with the 'U' vertical posture in UAX50 as if they had the
'Tr' vertical posture. One typical example with this type of
incompatibility in existing fonts can be seen in U+2016 DOUBLE VERTICAL
LINE. The UAX50vert won't have the glyph for the character. The number of
glyphs affected by this type of incompatibility is small.

    I will continue to consider this issue some more . . . .

    Regards,

    --Taro





-- 
Regards,
Makoto