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月11日(水) 8:41
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>
Cc: Taro Yamamoto <tyamamot@adobe.com>, Florian Rivoal <florian@rivoal.net>,
Nat McCully <nmccully@adobe.com>, MURATA Makoto (FAMILY Given) <
eb2m-mrt@asahi-net.or.jp>


Folks,

Here is my plan.

   - In an APL seminar (January) for publishers, I will point out this
   issue.  This is to make publishers aware of this issue.
   - In another seminar (Februrary) of Japanese Character Information
   Technology Promotion Council (CITPC), I will repeat the same talk but put
   more emphasis on technical issues.  This is to tell font vendors that
   publishers care.
   - A subcommittee of CITPC, which is chaired by me, investigates ALL
   characters in JIS X 0213 carefully.
   - In the JWG, we will discuss possible solutions.  I expect that  some
   enhancement to OpenType is needed.  This will take at least a year.
   Probably, two years.
   - Of course, I will keep in touch with Taiwanese.  Should somebody from
   HongKong be involved?
   - Some errata to Writing Modes or even the 2nd edition can hopefully be
   published by W3C.

Regards,
Makoto

2019年12月11日(水) 7:53 fantasai <fantasai@inkedblade.net>:

> 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


-- 
Regards,
Makoto