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

---------- Forwarded message ---------
From: fantasai <fantasai@inkedblade.net>
Date: 2019年12月11日(水) 7:53
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>
Cc: Florian Rivoal <florian@rivoal.net>, MURATA Makoto <
eb2m-mrt@asahi-net.or.jp>, Nat McCully <nmccully@adobe.com>


On 12/9/19 8:49 PM, Taro Yamamoto 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.

Quotes, brackets, dashes, and rules all should have 'vert' alternates, and
in
most cases they will be rotated. This is normal and expected, even by
Writing
Modes: any other presentation would be clearly wrong, even for fully
upright
typesetting.

Equal sign and arrows are a bit more problematic, because typesetting them
truly upright is legitimate, and having a 'vert' feature which rotates them
prevents this possibility.

BTW: You might find it interesting, but Writing Modes originally specified
arrows to to be rotated by default, before UAX50 existed:

https://www.w3.org/TR/2011/WD-css3-writing-modes-20110901/#vertical-typesetting-details
(I think this was one case where Eric Muller and I disagreed strongly.)

>      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,

No, 'Tr' and 'Tu' glyphs should all have 'vert' alternates (and be typeset
with those alternates by default). The difference is:
'Tu' glyphs, if no 'vert' alternate, cannot synthesize by rotating
'Tr' glyphs, if no 'vert' alternate, can synthesize by rotating

'Tr' glyphs might want to *also* have 'vrtr' feature, if pure rotation by
application is not appropriate when typographer tries to set them to 'R'
intentionally. But I am not sure it's necessary.

> 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?

CSSWM/UAX50 envisions that if 'R' characters need a variant glyph for
typesetting in vertical text, then 'vrtr' can be used to provide it. But
also,
if typesetter wants to typeset the text upright, then 'vert' alternate, if
any, provides upright orientation.

For example, equal sign may be rotated by default, but sometimes
typesetters
want to set it upright. In such cases, if the 'vert' alternate is rotated,
the
typesetter cannot be happy: there is no way to make it upright.

> 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.

I think this is an error in UAX50, then. We should fix it.

I think that every dash in Pd class (except PRESENTATION FORM FOR VERTICAL)
should be R or Tr, and that even 'R' dashes should have a 'vert' alternate
with a rotated glyph, because even in upright styles of typesetting, it
would
be desired to have them rotated.

> 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 don't think I understand. What is the situation with U+2016?

=====

It seems to me we have several problems to solve here:
   1. Clarify expectations for fonts to be used with UAX50+CSSWM
   2. Find errors in UAX50 such as U+2015 and get them fixed.
   3. Figure out some backwards-compatible solution for characters
      such as arrows and equal sign, which a typesetter could very
      reasonably want upright, but whose 'vert' glyphs are traditionally
      rotated in CJK fonts.

For problem #2, maybe you and Nat can make some report of all the
characters
which have problems, and we can review them together to see which ones
should
be fixed by updating UAX50 tables? Then we can make a joint proposal to
Unicode to update UAX50. I hope that if we present together a specific
proposal, we can convince Unicode to make such updates.

For problem #3, basically, the goals we have are:
   a) Typesetter should be able to typeset sideways (this is easy)
   b) Typesetter should be able to typeset upright (this is problematic)
   c) Default probably should match existing practices, so long as this
      is not fundamentally incompatible with the intention of UAX50
It's not hard to solve c) I think. The problem we have is b). I think
anything
we do will be awkward...

Maybe one possible solution could be
   * Change their classification in UAX50 to new value similar to 'R' or
'Tr'
   * Add a new OpenType feature 'vrtf' (force vertical).
   * When typesetter chooses 'upright' orientation, if font supports 'vrtf',
     use 'vert' + 'vrtf' feature so 'vrtf' can override 'vert' for such
     characters, otherwise disable 'vert' for such characters.
?

~fantasai



-- 
Regards,
Makoto