- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Wed, 25 Dec 2019 20:18:33 +0900
- To: Taro Yamamoto <tyamamot@adobe.com>
- Cc: fantasai <fantasai@inkedblade.net>, Florian Rivoal <florian@rivoal.net>, Nat McCully <nmccully@adobe.com>, www-archive@w3.org
- Message-ID: <CALvn5EAEaU12T9Oe9MNdQLS3kAV2qpYBaj7agQP=W+umB93Cfg@mail.gmail.com>
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
Received on Wednesday, 25 December 2019 11:19:14 UTC