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月24日(火) 13:51
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,



I exported your Excel file into a csv file. After modifying the format a
little, I wrote a script to convert it to a PostScript file with vertical
glyphs specified by the ‘vert’ feature. I attach its PDF version.

Nat and I are internally investigating this issue nwo, checking our own
fonts. I guess that based on it, Nat will restart the discussion with more
concrete data.



But please note that our members in the United States have already entered
the year-end holiday season.

Some of your colleagues are also in the holiday season already, I guess.

Best wishes for your merry Christmas and happy new year!



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