From: mpsuzuki@hiroshima-u.ac.jp
Date: Wed Mar 14 2007 - 12:21:38 CST
Dear Sir,
Great Thank you for quick answer!
On Tue, 13 Mar 2007 21:17:25 -0700
Ken Lunde <lunde@adobe.com> wrote:
> With regard to Comment 3, we have not yet defined the OpenType
> implementation of IVSes. Our current thinking is that it will not be
> done via the 'cmap' table.
I agree, I guess extending 'cmap' to include IVS is difficult,
not good idea (it will increase the size of cmap table and
the cost to lookup a character, and always we will have to
pay extra cost to check the variant coverage and fallbacking)
> Thus, I cannot comment on Comment 3 at
> this time. It is implementation-dependent.
Umm, my question in comment 3 was insufficiently explained.
UTS #37 "Ideographic Variation Database" shows the
application of IVSes driven by concrete shapes for
a codepoint U+82A6 (Appendix B). For such purpose,
no abstraction is required to specify the glyph shape.
The document maker must know exact CID, if he want
to use Adobe-Japan1 glyph set. The variant selection
for U+9089 & U+908A are typical example: the forms
of characters are given as is, not refering other
standards or documents.
There is another kind of requirement: "all ideograph
shapes in this document should be JIS90-compliant,
but I don't know the exact forms of JIS90-compliant
glyphs, so I want to use the CIDs which Adobe defines
JIS90-compliant". According to Adobe TechNotes #5078,
there are large groups of CID that their forms are
refering JIS (or other standards) and the forms of
KozMinProVI is just an exempling instance.
If we have CFF OpenType supporting Adobe-Japan1, there
might be 2 methods to select a glyph for such purpose:
one is direct selection by CID, another is selection
by the combination of Unicode codepoint and OT layout
tag "jpXX" families.
The former method had ever been specialized for PS/PDF-
related frameworks (e.g. Apple Glyph Access protocol is
such this kind, but it is designed for internal use).
For the viewpoint of information interchange, the latter
method had been prefered.
But the IVSes (for IVD Adobe-Japan1) makes this method
available in plain coded text for information interchange.
Thus, I think, the compatibility between former and latter
method will be important. Here, I restrict the scope to
CFF OpenType including Adobe-Japan1 that both methods are
available (although OT layout "jpXX" tags are applicable
to non-Adobe-Japan1 CFF OpenType and non-CFF OpenType etc,
only the latter method is available in these fonts).
If I have CID-keyed font for Adobe-Japan1 and I'm to make
CFF OpenType from it, Adobe TechNote #5078 should be
sufficiently informative to define "jpXX" tags' GSUB tables
to append for CFF OpenType, I guess. So I think it is expected
that the relashionship between Adobe-Japan1 CID and OT-tag
for CFF OpenType is clarified.
> With regard to the other comments, it points to a needed revision of
> Adobe Tech Note #5078.
# I think you mean comments 4-9 by "other comments", and
# I think I don't receive comments 1-2 not yet.
No, my comment 5, 6, 7 are about the source of forms which
had ever been introduced for legacy vendor character sets
and later redefined as forms for JIS. My comment 9 is a
request of clarification of sources of APGS-compatible glyphs
in Adobe-Japan1-5.
> In fact, we have built JIS2004-savvy fonts
> based on Adobe-Japan1-6, but they are not yet released. The details
> of building such fonts, as they differ from JIS90-savvy fonts, is a
> useful addition to that Adobe Tech Note.
Possibly the issue about JIS2004-compliancy is relaed to
my comment 1 & 2. I want to receive answers for them.
Regards,
mpsuzuki
This archive was generated by hypermail 2.1.5 : Wed Mar 14 2007 - 12:25:52 CST