IFX Mail Archive: IFX> New Version of PDF/is Spec is now ava

IFX Mail Archive: IFX> New Version of PDF/is Spec is now ava

IFX> New Version of PDF/is Spec is now available (0.5).

From: Rick Seeler (rseeler@adobe.com)
Date: Fri Dec 20 2002 - 13:05:02 EST

  • Next message: Rick Seeler: "IFX> IFX phone conference."

    I just found out that my message that I sent out yesterday did not get
    posted. (Probably because I had an attachment). Here it is again...


    The new version of the PDF/is specification (0.5) is available at:
    ftp://pwg.org/pub/pwg/QUALDOCS/pwg-ifx-pdfis-P05-021219.pdf and

    To answer comments made by Robert Buckley and others (privately), I have
    made the following changes to the PDF/is specification:

    1) The terms 'Creator' and 'Renderer' have been replaced with 'Producer' and
    'Consumer' to match terminology used in the PDF Reference.
    2) Support for 'Flate', 'JPEG', and 'Masking' are now considered 'required'
    by the Consumer. This was changed in the interest of creating a format that
    has fewer options.
    3) Support for 'CalGray', and 'CalRGB' were dropped from the spec in favor
    of 'DeviceGray' and 'DeviceRGB' color spaces.
    4) 'DeviceRGB' is defined to represent sRGB.
    5) 'DeviceRGB', 'DeviceGray' and 'Lab' color spaces are now 'required' by
    the Consumer.
    6) The 'Dependency' column of Table 3-5 has been removed since no features
    depend on any other features as the spec is now written.
    7) Support for JBIG2 Profile 1 (See T.89) has been added to the JBIG2
    support in addition to Profile 4.
    8) Objects in the 'cache hold' can now be 'freed' in the middle of the
    'Content Stream'.
    9) 'Banding' has now been upgraded to full 'Tiling' support.
    10) 'Adobe.PPKLite' has been removed as the required 'Filter' name for
    encryption and Dsig.
    11) Various other minor changes -- See notes in PDF at:

    Current outstanding issues:
    1) In the interest of blind-interchange, should JBIG2 rendering support be
    required of all consumers? The only other 'Optional' features in the spec,
    as it now stands are:
            A) Standard Encryption.
            B) PPK Encryption.
            C) Digital Signaturing.
    Here are my feelings on each of these:
            A - May require licensing of RC4 encryption software. Standard
    encryption requires a target device that can query and take a password as
    input: this may not be practical for all types of devices. This should
    remain an option.
            B - May require licensing of encryption software. PPK encryption
    requires that the consumer have a public key that the producer can retrieve
    via IPP (or some other mechanism). A 'profile' isn't necessary for this
    feature: if the producer is unable to get the consumer's public key, the
    producer will not be able to use this feature.
            C - A Digital Signature may be applied to any document. The
    consumer doesn't have to validate the signature if they don't wish to, or
    are not able to do so.

    2) Should we "hard code" a minimum buffer size for the memory cache value
    (Section instead of making this another parameter?

    3) A proposal from Xerox that I'm not sure I can answer right now: "General
    comment about DID and Annotation fields, and the possibility of using one or
    the other as a mechanism for including a "fax transmit header" or sender-uri
    value, per Sec. 9.5 in IPPFAX 1.0 Protocol Draft. Right now the
    recommendation is to burn it into the image data, but the DID or Annotation
    field could be used for this attribute value--consider text to this effect
    in 3.3.19 or 3.3.17."

    Rick Seeler
    Technical Lead - Strategic Technology Team
    Print Workflow Products Group
    Adobe Systems Incorporated
    Mailstop E13
    321 Park Ave.
    San Jose, CA 95110
    V. (408) 536-4393
    F. (408) 537-8077

    This archive was generated by hypermail 2b29 : Fri Dec 20 2002 - 13:05:26 EST