W3C home > Mailing lists > Public > www-archive@w3.org > December 2019

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

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Wed, 25 Dec 2019 20:16:09 +0900
Message-ID: <CALvn5ECf=mAR8969DjKqAoh9BCUSmWrwpoL4Ez8aMU7k7HYZDQ@mail.gmail.com>
To: www-archive@w3.org
---------- Forwarded message ---------
From: Taro Yamamoto <tyamamot@adobe.com>
Date: 2019年12月25日(水) 15:52
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>


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?



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

Received on Wednesday, 25 December 2019 11:17:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:17 UTC