Re: Comment on PRI 98: IVD Adobe-Japan1 (pt.3)

Date: Wed Mar 14 2007 - 12:21:38 CST

  • Next message: Philippe Verdy: "RE: ISO 6429 control sequences with non-ASCII CES's"

    Dear Sir,

    Great Thank you for quick answer!

    On Tue, 13 Mar 2007 21:17:25 -0700
    Ken Lunde <> 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.


    This archive was generated by hypermail 2.1.5 : Wed Mar 14 2007 - 12:25:52 CST