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

Yamamoto-san,

Thanks for your hard work.  You investigated glyph!

Category A is problematic.  We have to take some action.
U+2016 ‖
U+2702 ✂

Category E is also problematic.  We have to take some action at least for
U+3030.
U+3030 〰
U+ff01 ！
U+ff1b ；
U+ff1f ？

Categories B and C: If I am not missing anything, no characters are in
these categories.

Category D has several characters and is debatable.   I would like to ask
font vendors in CITPC .

2019年12月25日(水) 15:52 Taro Yamamoto <tyamamot@adobe.com>:

> Dear all,
>
>
>
> Sorry, I updated the file again.
>
> Though I wrote the following, I was wrong. Murata-san’s original file was
> correct. 😉
>
>
>    - 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.
>
>
>
> But I found that his file contained 159 duplicate entries, of which four
> are classified in the ‘D’ category of possible incompatibility with UAX
> #50. These duplicates seem to be needed, because one of the is for JIS X
> 0201 and the other for JIS X 0213?
>
>
>
Yes, I used this mapping table.

http://x0213.org/codetable/jisx0213-2004-8bit-std.txt

It is not official, but appears to be well maintained.
I forwarded Yamamoto-san's mail to www-archive.

Regards,
Makoto


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