- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Thu, 12 Dec 2019 13:50:45 +0900
- To: www-archive@w3.org
- Message-ID: <CALvn5EDtvbTceudeUe8vP7=MYWvxN=GfRujDhe6gVOuqp+9e7g@mail.gmail.com>
---------- Forwarded message ---------
From: Taro Yamamoto <tyamamot@adobe.com>
Date: 2019年12月11日(水) 17:58
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: Florian Rivoal <florian@rivoal.net>, MURATA Makoto <
eb2m-mrt@asahi-net.or.jp>, Nat McCully <nmccully@adobe.com>
Fantasai,
Thank you very much for your detailed comments and explanations!
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.
VerticalOrientation.txt says, for example:
2010..2015 ; R # Pd [6] HYPHEN..HORIZONTAL BAR
As mentioned above, InDesign seems to be treating this
as not as an R but Tr glyph, and our fonts have it in the 'vert' feature.
It seems important that InDesign is treating these as
'Tr' glyphs, only when such are thought to be used as full-width Japanese
characters. For example, U+2014 EM DASH (and other similar dashes) are
treated not as a 'Tr' characters but as 'R' characters conforming to the
definitions in UAX50.
2016 ; U # Po DOUBLE VERTICAL LINE
InDesign also seems to be treating this as a 'Tr' glyph,
and our fonts have this in the 'vert' feature. This is incompatible with
UAX50.
Having looked at these two examples, it became difficult for me how these
could be related to what you wrote above. It seems these are not regarded
as "dashes", if my understanding of what you wrote above; viz. you seem to
regard dashes, etc., you wrote above, as Tr glyphs, by UAX50. If my
interpretation of what you wrote is wrong, please so advise me.
On the other hand, the vertical version of the
HORIZONTAL BAR character is defined as 'Tr' by UAX50
FF5C ; Tr # Sm FULLWIDTH VERTICAL LINE
Quotes, two dots, three dots, tend to be defined as R by UAX50 as shown
below, but our 'vert' table has many of them, as I wrote previously,
because they are treated as 'Tr' glyphs.
2017 ; R # Po DOUBLE LOW LINE
2018 ; R # Pi LEFT SINGLE QUOTATION MARK
2019 ; R # Pf RIGHT SINGLE QUOTATION MARK
201A ; R # Ps SINGLE LOW-9 QUOTATION MARK
201B..201C ; R # Pi [2] SINGLE HIGH-REVERSED-9 QUOTATION
MARK..LEFT DOUBLE QUOTATION MARK
201D ; R # Pf RIGHT DOUBLE QUOTATION MARK
201E ; R # Ps DOUBLE LOW-9 QUOTATION MARK
201F ; R # Pi DOUBLE HIGH-REVERSED-9 QUOTATION MARK
2020..2021 ; U # Po [2] DAGGER..DOUBLE DAGGER
2022..2027 ; R # Po [6] BULLET..HYPHENATION POINT
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.
FF1C..FF1E ; R # Sm [3] FULLWIDTH LESS-THAN SIGN..FULLWIDTH
GREATER-THAN SIGN
FF1D FULLWIDTH EQUALS SIGN is defined as R character,
while our fonts have it in the 'vert' feature, and it seems to be treated
as a 'Tr' glyph instead.
BTW: You might find it interesting, but Writing Modes originally
specified
arrows to to be rotated by default, before UAX50 existed:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2011%2FWD-css3-writing-modes-20110901%2F%23vertical-typesetting-details&data=02%7C01%7Ctyamamot%40adobe.com%7Cc2517fb62ed74f14acf808d77dc3c9a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637116152172784086&sdata=nV%2Bzb3ESCoYk%2BuMfubji8WOCDl1dzp1eNcSMBz0Nl%2Bw%3D&reserved=0
(I think this was one case where Eric Muller and I disagreed strongly.)
Arrows are currently defined to be R by UAX50, aren't they?
2190..2194 ; R # Sm [5] LEFTWARDS ARROW..LEFT
RIGHT ARROW
> 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
I feel a limitation of expressing and understanding this issue in a natural
language. I try to express it in a pseudo-code.
My current understanding of your explanation seems to be expressed in the
following way:
*If *a hypothetical pseudo-character → (whose image on the left shows its
horizontal upright posture) has the UAX50 vertical posture 'U':
*If* the font has the 'vert' feature:
The 'vert' FEATURE IS ALWAYS APPLIED BY THE APPLICATION to get
the output glyph:
*If* the glyph is included in the 'vert' feature:
If the 'vert' feature treats the character as a 'Tr'
glyph, and outputs a "pseudo-rotated' glyph ↓:
IT WILL BE INCOMPATIBLE WITH UAX50, because the
expected output has its upright shape →.
*else:*
The output result will be COMPATIBLE WITH UAX50.
(Some design-dependent glyph shape adjustment for the vertical mode might
be applied though).
The application USES THE OUTPUT GLYPH in the
UPRIGHT posture for the vertical composition, WITHOUT ROTATING THE ORIGINAL
HORIZONTAL GLYPH.
*else:*
The application output the horizontal UPRIGHT glyph as
is.
*else:*
The application output the horizontal UPRIGHT glyph as is.
*elif* the pseudo-character → has the UAX50 vertical posture 'Tu':
*If* the font has the 'vert' feature:
The 'vert' FEATURE IS ALWAYS APPLIED BY THE APPLICATION to get
the output glyph:
*If* the glyph is included in the 'vert' feature:
If the 'vert' feature treats the character as a 'Tr'
glyph, and outputs a "pseudo-rotated' glyph ↓:
IT WILL BE INCOMPATIBLE WITH UAX50, because the
expected output has its upright shape →.
*else:*
The output result will be COMPATIBLE WITH UAX50.
(with some adjustment to the glyph design, typically, about its
positioning).
The application uses THE OUTPUT GLYPH in the
UPRIGHT posture for the vertical composition, WITHOUT ROTATING THE ORIGINAL
HORIZONTAL GLYPH.
*else:*
The applications output the horizontal UPRIGHT glyph as
is, but it may fail to represent the expected glyph shape of 'Tu' because
it cannot be obtained from the font. →
*else:*
The application output the horizontal UPRIGHT glyph as is, but
it may fail to represent the expected glyph shape of 'Tu' because it cannot
be obtained from the font. →
*elif* the pseudo-character → has the UAX50 vertical posture 'Tr':
*If* the font has the 'vert' feature:
The 'vert' FEATURE IS ALWAYS APPLIED BY THE APPLICATION to get
the output glyph:
*If* the glyph is included in the 'vert' feature:
*If* the 'vert' feature treats the character NOT as a
'Tr' glyph, and the output glyph does not have the "pseudo-rotated' effect:
IT MAY BE INCOMPATIBLE WITH UAX50, because the
expected output has the "pseudo-rotated" shape, but it is not output →.
*else:*
The application DOES NOT ROTATE the horizontal
UPRIGHT glyph, but uses the output glyph of the 'vert' feature.
The output result will be COMPATIBLE WITH UAX50.
(with the "pseudo-rotated" effect) ↓
The application uses THE OUTPUT GLYPH in the
PSEUDO-ROTATED posture for the vertical composition.
*else:*
The application handles the horizontal UPRIGHT glyph by
itself, possibly by rotating the horizontal UPRIGHT glyph, but it may fail
to represent the expected glyph shape of 'Tr' because it cannot be obtained
from the font. ↓
*else:*
Without the 'vert' feature, application handles the horizontal
UPRIGHT glyph by itself, possibly by rotating the horizontal UPRIGHT glyph,
but it may fail to represent the expected glyph shape of 'Tr' because it
cannot be obtained from the font. ↓
*elif* the pseudo-character → has the UAX50 vertical posture 'R':
*If* the font has the 'vert' feature:
The 'vert' FEATURE MUST NOT BE USED by the application. Any
applications that use the 'vert' feature can be regarded as UAX50
INCOMPATIBLE applications.
*elif* the font has the 'vrtr' feature:
The 'vtrt' FEATURE IS ALWAYS APPLIED BY THE APPLICATION to get
the expected glyph before rotation.
*If* the glyph is included in the 'vtrt' feature:
The application gets THE OUTPUT GLYPH AND ROTATES IT for
use in the vertical writing mode. ↓
*else:*
The application ROTATES THE HORIZONTAL UPRIGHT GLYPH for use in
the vertical writing mode. ↓
Is this understanding correct?
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.
If ‘vtrt’ characters are assumed to be rotated by the application always,
even with some modified glyph shape, it doesn’t seem to avoid the current
existing InDesign’s incompatibility with UAX50 about the above-mentioned R
characters treated as ‘Tr’ glyphs by InDesign, included in the ‘vert’
feature, because the intended purpose was to prevent the glyphs from being
automatically rotated by the application, but to provide the application
with the ‘pseudo-rotated’ glyph shapes, so that high precision in the
‘pseudo-rotated’ output results should be guaranteed.
>> 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?
Today, I could not come up with your last discussion. Sorry. Tomorrow, I
will peruse the rest of your message.
Thank you again for your kind help.
Regards,
--Taro
--
Regards,
Makoto
Received on Thursday, 12 December 2019 04:51:27 UTC