From: mpsuzuki@hiroshima-u.ac.jp
Date: Tue Mar 13 2007 - 18:53:29 CST
Dear Sirs,
This post is last, my comments 3-9.
Except of comment 3 (interoperability with OpenType font),
most comments on this post are rather for Adobe TechNote #5078
itself than for PRI 98. I think, the primal form definitions
for each CIDs are expected to be clarified, even if the answer
is simply "KozMinProVI-Light is the primal definition, it is
provided as is" (the assertion is sufficiently helpful).
Regards,
mpsuzuki
--
Adobe TechNote #5078 includes very helpful informations
about the references of glyph design (which standard
the glyph should be compliant to, and which document
we should refer to). However, there are several mismatch
between the roots of CIDs and the codepoint in IVD.
In following, I describe in detail.
I think there are 3 groups of CIDs in Adobe-Japan1.
1. CID whose glyph should be designed with reference
to Japanese Industrial Standards (JIS).
2. CID whose glyph are designed to display existing
"proprietary" system out of Adobe.
2-a. CIDs whose glyphs are shared by legacy
PostScript systems, like, Morisawa OCF.
ex. Adobe-Japan1-0.
2-b. CIDs for "vendor character set".
ex. Microsoft Windows 3.1 J,
Apple Kanji Talk 6,
Fujitsu FM-R.
2-c. CIDs for character set not by JIS or software
vendors (so no specific implementations nor
platforms are assumed).
ex. National Language Council, K-JIS, U-PRESS, etc.
3. CID whose glyph does not refer any existing documents.
About group 1 (CID for JIS)
===========================
Comment 3: OT-tag interoperability?
-----------------------------------
Unfortunately, current TrueType font format specification
cannot include the cmap table including IVS (>= 32bit).
So, OpenType layout feature will be quite important to
support IVS.
In OpenType, Adobe had already introduced the feature tags
to specify the ideographic variant by JIS revision:
"jp78", "jp83", etc:
http://partners.adobe.com/public/developer/opentype/index_tag6.html#jp78
http://partners.adobe.com/public/developer/opentype/index_tag6.html#jp83
http://partners.adobe.com/public/developer/opentype/index_tag6.html#jp90
http://partners.adobe.com/public/developer/opentype/index_tag6.html#hojo
http://partners.adobe.com/public/developer/opentype/index_tag7.html#nlck
http://partners.adobe.com/public/developer/opentype/index_tag6.html#jp04
For convenient interoperability between text with ideographic
variant specification by "jpXX" OT-tag and that by IVS,
I wish if Adobe defines the mapping table of which Adobe-Japan1
IVS should be used for these OT-tag. ("nlck" might be slightly
different category, sorry)
About group 2 (CID shared by legacy PS systems)
===============================================
About 2-a. CIDs shared by legacy PS systems
===========================================
Comment 4: Requirement of JIS90 compliancy
------------------------------------------
Now, Adobe TechNote #5078 notes about JIS90-compliancy, as:
"In order for Adobe-Japan1-4 CID-keyed fonts to be useful and
meaningful, the glyphs of all JIS X 0208:1997 kanji must be
JIS90-compliant. This affects CIDs 1125 through 7477 (6,353
CIDs) in Supplement 0, and CIDs 8284 and 8285 in Supplement 1.
Some subtle glyph variations in Supplement 4 (see Section 7)
make this necessary." (p. 5)
"In order to ensure glyph consistency across fonts of different
manufactures, the JIS X 0208:1997 kanji (CIDs 1125-7477 and
8284-8285 of Supplements 0 and 1, respectively) must become
JIS90-compliant. This is due to the fact that some of the JIS
X 0208:1997 kanji variants in the Adobe-Japan1-4 are sometimes
subtle in their difference with their JIS90 (standard) forms".
(p. 95)
In both paragraphs, it seems that the JIS90-compliancy is
requested as a part of Adobe-Japan1-4. It means that the request
was introduced when Adobe-Japan1-4 was defined, and the legacy
Adobe products before Adobe-Japan1-3 are not (guaranteed to be)
JIS90-compliant?
According to TechNote #5078 p. 221, Adobe-Japan1-1 & -2 (1994)
specification were printed by Morisawa's RyuminPro-Light.
I remember, OCF Ryumin-Light was designed before JIS90 (1988?)
so it is possible that original Ryumin-Light forms are not
compliant with JIS90. Unfortunately, Morisawa removed the glyph
difference data between their OCF and their 1st CID-keyed font,
I could not check in concrete example.
About 2-b. CIDs for vendor defined charset
==========================================
Comparing with group 1 and group 2-a, it slightly unclear what
we should refer as primal definition.
CID 7633-7886: TechNote notes nothing in detail, used for various
charset: 78-XXX (CMap for legacy JIS C 6226-1978),
UniJIS-XXX (intersection of JIS X 0208 & UCS2),
Ext-XXX (NEC), NWP-XXX (NEC word processor Bungo),
Add-XXX (Fujitsu FM-R),
83pv-XXX (KanjiTalk 6), 90pv-XXX (KanjiTalk 7),
90ms-XXX (Windows 3.1 J).
CID 7958-8004: TechNote notes nothing in detail, but used for single
charset": used by only Add-XXX CMap (Fujitsu FM-R)
CID 8359-8717: TechNote notes "to support the Microsoft Windows 3.1 J
character set". However, CID 8561 & 8592 are later
classified as glyphs for JIS X 0212:1990 (p. 196)
To note from easier to harder, I describe 2nd, 3rd and 1st region.
Comment 5: primal glyph definition of FM-R characters
-----------------------------------------------------
The 2nd region (CIDs for Fujitsu FM-R) is easy. Refering Fujitsu
product (if available still), or use existing Adobe product
(e.g. KozMinProVI-Light) as the primal definition is simplest.
CID 7963 (originally FM-R Shift-JIS 0x8952) is the unique CID for
U+5653 which is now a part of latest Japanese charset JIS X 0213:2004,
so it might be helpful to state whether CID 7963 must be JIS X
0213:2004 compliant, or doesn't have to be.
# IMHO, FM-R charset was based on legacy JIS78, so we can expect
# the FM-R RKSJ 0x8952 is "traditional"-looking variant of U+5618,
# but we cannot assume the form is compliant to JIS X 0213:2004,
# so introduction of yet-another CID for U+5653 of JIS X 0213:2004
# may be simple for information interchange.
Comment 6: primal glyph definition of MS cp392 characters
---------------------------------------------------------
The 3rd region has small problem.
There are official specification of "Windows 3.1 J charset"
http://www.microsoft.com/globaldev/reference/dbcs/932.mspx
and official mapping to UCS2
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
Comparing the UCS2 codepoints for CIDs in this region,
there are several difference.
Microsoft CP932.TXT uses U+9592 as a character for ms-cp932
codepoints 0xEECC & 0xFBE8. For U+9592, Adobe-Japan1-6
provides 2 CIDs 8685 and 13693. CID 8685 was introduced
to support Microsoft Windows 3.1 J (Adobe-Japan1-2),
CID 13693 was introduced as JIS X 0208:1997 kanji variant
(Adobe-Japan1-4). I guess CID 13693 was originally introduced
to provide a variant form that JIS X 0208:1997 unifies
with U+9593. But, now, Adobe uses CID 13693 as a variant
of U+9592. I think the note in TechNote and mapping tables
should be consistent, as:
* possible fix 1: add note "Now CID 13693 is for IBM
Selected kanji variant." to fit ms-cp932.
* possible fix 2: move CID 13693 from a variant of U+9592
to that of U+9593 to fit JIS X 0208:1997.
CID 8542 (introduced in Adobe-Japan1-2) has another
inconsistency problem. According to Unicode specification
on CJK Compatibility Ideographs, "In addition, another
34 ideographs from various regional and industry standards
were encoded in this book, primarily to achieve round-trip
conversion compatibility. Twelve of these 34 ideographs
(U+FA0E, U+FA0F, U+FA11, U+FA13, U+FA14, U+FA1F, U+FA21,
U+FA23, U+FA24, U+FA27, U+FA28, and U+FA29) are not encoded
in the CJK Unified Ideographs Areas. These 12 characters
are not duplicates and should be treated as a small extension
to the set of unified ideographs" (The Unicode Standard 4.0,
p. 305). Thus (I guess), sequence.txt moves following CIDs
from original codepoints in CJK Compatibility Ideographs
to those in CJK Unified Ideographs.
CID cid2code IVS-base kIRG_JSource_of_IVS-base
8481 U+FA12 U+6674 0-4032 (JIS X 0208-1990)
8542 U+FA15 U+20611 *NONE*
8548 U+FA16 U+732A 0-4376 (JIS X 0208-1990)
8571 U+FA17 U+76CA 0-3157 (JIS X 0208-1990)
8579 U+FA18 U+793C 0-4E69 (JIS X 0208-1990)
8580 U+FA19 U+795E 0-3F90 (JIS X 0208-1990)
8581 U+FA1A U+7965 0-3E4D (JIS X 0208-1990)
8583 U+FA1B U+798F 0-4A21 (JIS X 0208-1990)
8587 U+FA1C U+9756 0-4C77 (JIS X 0208-1990)
8590 U+FA1D U+7CBE 0-403A (JIS X 0208-1990)
8599 U+FA1E U+7FBD 0-3129 (JIS X 0208-1990)
8612 U+FA20 U+8612 1-5A29 (JIS X 0212-1990)
8622 U+FA22 U+8AF8 0-3D74 (JIS X 0208-1990)
8633 U+FA25 U+9038 0-306F (JIS X 0208-1990)
8636 U+FA26 U+90FD 0-4554 (JIS X 0208-1990)
8699 U+FA2A U+98EF 0-4853 (JIS X 0208-1990)
8700 U+FA2B U+98FC 0-3B74 (JIS X 0208-1990)
8702 U+FA2C U+9928 0-345B (JIS X 0208-1990)
8715 U+FA2D U+9DB4 0-4461 (JIS X 0208-1990)
As shown in this list, most base codepoints mapped by
IVS are the characters that have JIS sources and easy
to reduce to union of JIS charsets for information
interchange. But CID 8542 is exceptional, its IVS base
codepoint U+20611 has no JIS source.
According to legacy CMaps designed for Adobe-Japan1-2
(90ms-RKSJ-H, UniJIS-UCS2-H), CID 8542 seems to be
introduced to display ms-cp932 codepoints 0xEDF9 & 0xFB58
(CP932.TXT maps them to U+FA15). Recent CMaps
(UniJIS-UTF16-H, UniJIS-UTF32-H, UniJISX0213-UTF32-H)
displays U+FA15 by CID 20307. According to TechNote #5078,
CID 20307 was introduced as a glyph for JIS X 0213:2004
compliancy, and sequence.txt defines CID 20307 as one
of variant forms of U+51DE.
On the other hand, sequence.txt defines CID 8542 as
one of variant forms for U+20611. According to Unihan.txt,
CID 14294 is canonical form of U+20611 and CID 8542
is variant form of U+20611. Anyway, U+20611 is not
included in legacy JIS charsets (JIS X 0208, JIS X 0212,
JIS X 0213), so using (variant of) U+20611 for legacy
ms-cp932 codepoint is slightly confusing.
I think taking CID 8542 as variant of U+51DE (included
in JIS X 0212 and JIS X 0213) is better for information
interchange.
* possible fix 1: redefine CID 8542 from a variant form of
U+20611 to that of U+51DE, for ms-cp932-derived
systems' information interchange.
* possible fix 2: add note "Now CID 20307 is used for IBM
Selected kanji, but JIS X 0213:2004 compliant
form", to indicate glyph difference from CID 8542.
Comment 7: primal glyph definition of CID shared
------------------------------------------------
by several vendor character set
-------------------------------
The 1st region is difficult.
These CIDs had ever been introduced by Adobe-Japan1-0
for compatibility with legacy PS system. Although
legacy 78-XXX CMaps had ever used them as CIDs for
JIS78 charset, current TechNotes #5078 does not
define them as their glyphs must be JIS78-compliant,
or not. As Ken Lunde's "CJKV" notes (p. 919), there
is large group of source-dependent (in the other words,
JIS didn't clarified) form difference of JIS C 6226-
1978 versus JIS X 0208-1983 (or JIS X 0212-1990).
Thus it is reasonable to assume the glyph shapes
for JIS78 characters in legacy PS systems (designed
before 1990) are not guaranteed to be JIS78-compliant.
Strictly JIS78-compliant glyphs are introduced
in Adobe-Japan1-4 and Adobe-Japan1-6. I think using
these newer CIDs are more exact to specify JIS78-
compliant glyph.
Recent CMaps from Unicode codepoint to CID number
is not appropriate to refer as glyph definition.
The rest CMaps are all vendor defined charsets:
it is difficult to determine the priorities of them,
although Windows 3.1 J might be most popular one
(others are not registered charset in IANA).
As a result, it might be acceptable to use exisiting
Adobe product as the primal glyph definition.
In addition, some CIDs in this region are defined
as a (variant) form of non-JIS character. Considering
the history that these CIDs are introduced for
legacy PS systems, using non-JIS cjaracter as
a basis of these CIDs are slightly confusing for
information interchange.
CIDs has no Japanese source (no JIS nor Japanese
vendor character set).
CID IVS_base_codepoint similar_JIS_character
7641 U+28CDD U+958F (JIS78 form?)
7670 U+25874 U+7A3D (JIS78 form?)
7672 U+8346 U+834A (JIS78 form?)
7673 U+28EF6 U+9699 (JIS78 form?)
7687 U+6805 U+67F5 (JIS78 form?)
7825 U+21A1A U+5BC3 (JIS78 form?)
7834 U+67FA U+62D0 (JIS78 form?)
7836 U+688E U+688D (JIS78 form?)
7838 U+243D0 U+71D7 (JIS78 form?)
CIDs mapped to character from "Unified Japanese IT
Vendors Contemporary Ideographs, 1993" (but no JIS
source).
7655 U+3D4E U+6F97 (JIS78 form?)
CIDs mapped to character from IBM CodePage 932
(but no JIS source).
7680 U+663B U+6602 (JIS78 form?)
CIDs mapped to Unicode character included in JIS X
0213
CIDs included by JIS X 0213:2000
7715 U+87EC U+8749 (trad. kanji)
7727 U+9A52 U+9A28 (trad. kanji)
7739 U+7C1E U+7BAA (trad. kanji)
7861 U+853E U+85DC (different?)
CIDs included by JIS X 0213:2004
7774 U+525D U+5265 (JIS78 form?)
7826 U+5C5B U+5C4F (JIS78 form?)
2-c. CIDs for non software vendor charset
=========================================
Comment 8: more detailed reference list might be
------------------------------------------------
expected.
---------
Adobe TechNote #5078 is just refering the name
(e.g. K-JIS, U-PRESS). I wish more detailed
references are given, as Ken Lunde's "CJKV" gives,
if KozMinProVI-Light is not primal glyph definition.
3. CID whose glyph does not refer any existing documents
========================================================
Comment 9: relationship with APGS
---------------------------------
For example, Adobe-Japan1-6 introduced 1986
Ideographs in CID 21071-23057. Among the
Ideographs, 3 CIDs (21072-21074) refer JIS
X 0213:2004, other 17 CIDs (21164, 21371,
21558, 21722, 21791, 21933, 22006, 22010,
22045, 22063, 22186, 22341, 22583, 22788,
22843, 22920, 23006) refer JIS X 0212-1990.
Other 1966 CIDs refer nothing. KozMinProVI-
Light is primal glyph definition?
In Adobe TechNote #5078, it is shortly noted
"to support the Apple Mac OS X Version 10.2
glyph set". Some documents published around
Apple says as 1966 CIDs are proposed to
Adobe-Japan1-5, as a part "Apple Publishing
Glyph Set" (APGS), based on collection of
glyphs in legacy CTP systems.
It might be expected to be noted: whether
Apple published glyphset definition of APGS
and 1966 CIDs should be compliant with,
or Adobe defines some compatible glyphset
and 1966 CIDs should be compliant with Adobe's
APGS-compatible glyphs.
# Unfortunately, Dainippon screen's Hiragino
# OpenTypes are the first (and only) implementation
# of real APGS font, but it is not reliable
# source as Adobe-Japan1 OpenType.
This archive was generated by hypermail 2.1.5 : Tue Mar 13 2007 - 21:36:08 CST