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

---------- Forwarded message ---------
From: Taro Yamamoto <tyamamot@adobe.com>
Date: 2019年12月25日(水) 15:16
Subject: Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?
To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, fantasai <
fantasai@inkedblade.net>, Florian Rivoal <florian@rivoal.net>, Nat McCully <
nmccully@adobe.com>


Murata-san et al,



I updated the list that was converted into PDF from your Excel file, which
I sent to you all with my last message, and I attached the latest version
to this message.



I changed my script, so that it could mark all the entries that might have
some incompatibility issue in red. Also to each of them, its type of
possible incompatibility is displayed. The categories are as follows;

Classes of Possible UAX #50-related  Incompatibility Issues:
A

A character whose vertical posture is ‘U’ according to UAX #50 is included
in the ‘vert’ feature, and its “Pseudo-rotated” glyph is output, as if its
vertical posture were ‘Tr’.



B

A character whose vertical posture is ‘Tu’ according to UAX #50 is included
in the ‘vert’ feature, and its “Pseudo-rotated” glyph is output, as if its
vertical posture were ‘Tr’



C

A character whose vertical posture is ‘Tr’ according to UAX #50 is included
in the ‘vert’ feature, but the ‘vert’ feature does not output its
“Pseudo-rotated” glyph, and it remains to be in an upright posture, as if
its vertical posture were ‘U’ or ‘Tu’.



D

A character whose vertical posture is ‘R’ according to UAX #50 is included
in the ‘vert’ feature, as if its vertical posture were ‘U’, ‘Tu’ or ‘Tr’.



E

A coded character which is supported by the ‘cmap’ table of the font, and
whose vertical posture is ‘Tu’ or ‘Tr’, is not included in the ‘vert’ table.


For example, if you find the character code U+2016, the following entries
two of which are enclosed within red frames can be seen. You can see that
U+2016 is classified into the class ‘A’, because its “pseudo-rotated” glyph
(CID+7895) is output by the ‘vert’ feature, in spite of its UAX #50
vertical posture type of ‘U’ (Upright). On the other hand, you can see the
character U+2015 is also incompatible with UAX #50, and its vertical
posture is defined to be ‘R’. Because it is assumed that characters with
the ‘R’ vertical posture should not be included in the ‘vert’ feature,
because such characters are assumed to be rotated by the layout engine
without the help of the ‘vert’ table. This type of possible incompatibility
is classified as ‘D’ in the list.



[image: スクリーンショット が含まれている画像 自動的に生成された説明]



By the way, Murata-san’s original list included only 63 of 132 entries
classified into the ‘D’ category of possible incompatibility issues. Also,
his original list included only one of four existing ‘vert’ entries that
can be classified as ‘E’. All the 132 entries categorized as ‘D’, as well
as the four entries categorized as ‘E’ are listed below.



Category D:

U+2015

U+2010

U+2026

U+2025

U+FF1D

U+00B0

U+2032

U+2033

U+2192

U+2190

U+2191

U+2193

U+2500

U+2501

U+2502

U+2503

U+2504

U+2505

U+2506

U+2507

U+2508

U+2509

U+250A

U+250B

U+250C

U+250D

U+250E

U+250F

U+2510

U+2511

U+2512

U+2513

U+2514

U+2515

U+2516

U+2517

U+2518

U+2519

U+251A

U+251B

U+251C

U+251D

U+251E

U+251F

U+2520

U+2521

U+2522

U+2523

U+2524

U+2525

U+2526

U+2527

U+2528

U+2529

U+252A

U+252B

U+252C

U+252D

U+252E

U+252F

U+2530

U+2531

U+2532

U+2533

U+2534

U+2535

U+2536

U+2537

U+2538

U+2539

U+253A

U+253B

U+253D

U+253E

U+253F

U+2540

U+2541

U+2542

U+2543

U+2544

U+2545

U+2546

U+2547

U+2548

U+2549

U+254A

U+21E9

U+21E7

U+21E6

U+21E8

U+23AB

U+23AC

U+23AD

U+23A7

U+23A8

U+23A9

U+27A1

U+2B95

U+2B05

U+2B06

U+2B07

U+261E

U+261C

U+261D

U+261F

U+21C6

U+21C4

U+21C5

U+21F5

U+239B

U+239D

U+239E

U+23A0

U+23A1

U+23A3

U+23A4

U+23A6

U+239C

U+239F

U+23A2

U+23A5

U+23AA

U+2B82

U+2B83

U+2B60

U+2B62

U+2B61

U+2B63

U+2B64

U+2B65

U+23B0

U+23B1



Category E

U+3030

U+FF01

U+FF1B

U+FF1F



It should be noted that these mentioned above apply to many (but not all)
Japanese fonts whose glyph sets are based on the Adobe-Japan1-x Character
Collection developed by Adobe, but these don’t apply to fonts with any
other glyph sets such as the Identity-0 Character Collection and glyph sets
for non-Japanese languages and scripts.



FYI



--Taro



*送信元**: *Makoto MURATA <eb2m-mrt@asahi-net.or.jp>
*日付**: *2019年12月24日 火曜日 11:54
*宛先**: *Yamamoto Taro <tyamamot@adobe.com>, fantasai <
fantasai@inkedblade.net>, Florian Rivoal <florian@rivoal.net>, Nat McCully <
nmccully@adobe.com>
*Cc: *Makoto MURATA <eb2m-mrt@asahi-net.or.jp>, "www-archive@w3.org" <
www-archive@w3.org>
*件名**: *Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?



With Yamamoto-san's help, I created a CSV file containing a tuple
containing:

- Unicode code point
- Unicode character
- CID (AJ1)
- cmap (UniJIS2004-UTF32-H or UniJISX02132004-UTF32-H)
- vert (AJ1 template)
- UAX#50 Tr/Tu/R/U
- draft SVO

It is available at:

https://1drv.ms/u/s!An5Z79wj5AZBgrkx0ohHD0zDhqCxxQ?e=ufWyFu
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!An5Z79wj5AZBgrkx0ohHD0zDhqCxxQ%3Fe%3DufWyFu&data=02%7C01%7Ctyamamot%40adobe.com%7C2c6cb52499ed4fc327a808d7881c9394%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637127528627254575&sdata=BLJKp3zcT0RpuijkBt%2F7phGuNYkKFwqQndNu8Zxn3SA%3D&reserved=0>

   1. Four Tr or Tu characters lack vert.  U+3030 〰 is
   particularly problematic.  Unlike the Adobe template, MS Mincho
   specifies the vert feature for this character.
   2. Many R characters have the vert feature, and is thus cannot
   be displayed as specified in the Unicode code chart.  U+2016 ‖ is
   a well-known example.  MS Mincho does NOT specify the vert feature for this
   character, though.
   3. Many SVO=R characters lack the vert feature.

Regards,

Makoto



2019年12月17日(火) 16:48 Taro Yamamoto <tyamamot@adobe.com>:

Murata-san,



   - They are caused by cmap resources dedicated to vertical writing.  In
   other words, for some character, vertical-writing cmap resources are used
   rather than vert.  Such characters include:


   -   . . .
   - I used below cmap columns in cid2code.txt.


   -  . . .


# o Column 27: Character codes for the "UniJISX02132004-UTF32-H" and
#   "UniJISX02132004-UTF32-V" CMaps (Unicode 13.0 UTF-32 encoding,
#   proportional Latin characters, some proportional JIS X 0208:1997
#   characters, JIS X 0213:2004 prototypical glyphs as the default).



It seems that you referenced the CMap files intended for use in the
vertical writing mode in the PostScript imaging model supporting the
CIDFont format, in which there is no other method to select vertical glyph
shapes, other than specifying a vertical font that can be referenced by
using a CMap file whose name has the ‘-V’ suffix. Such CMap files partly
and semantically similarly related to the ‘cmap’ table and ‘vert’ feature
that we are discussing in the context of the OpenType font format, but they
are separate things. Because of the existence of the ‘vert’ feature, an
OpenType font does not need to have the V version of a ‘cmap’ table, as far
as I understand.



Regards,



--Taro






-- 

Regards,

Makoto


-- 
Regards,
Makoto