IFX Mail Archive: RE: IFX> Conf Call Summary

IFX Mail Archive: RE: IFX> Conf Call Summary

RE: IFX> Conf Call Summary

From: Gail Songer (gsonger@peerless.com)
Date: Fri Mar 21 2003 - 15:46:47 EST

  • Next message: Gail Songer: "RE: IFX> New IPPFax specs posted"

    We currently have no plans for a Conf Call Friday March 28.

    Summary:

    1) Document structuring details. Rob has found performance differences
    with different document structures. (Also see Rob's questions and Rick's
    responses in the email archive March 21, 2003) Rick and Rob will take
    this offline.

    2) Need new attribute to query if the printer can/will interpret Digital
    Signatures. The receiver does not have to support them if they are in
    the file, they are Optional for both the Producer and the Consumer.
    But, the Producer MAY wish to query the Consumer to decide if it makes
    sense to DSig since it does increase the document size and takes
    processing power.

    Keyword of types supported. Need keywords. There is a spec on "IPP
    driver install" that enumerates all this

    3) Need PDF versions supported. Multivalued keyword. How to
    differentiate PDF and PDF/is...

    Need keywords for PDF and PDF/is (Example: there something from Adobe?
    PDF reference, section 3.4.1, Third edition). PDF/is-1.0. TomH has
    the keyworks for PDFx ISO standards.

    4) Ira would prefer to remove Encryption. IPP can already use TLS to
    encrypt on the wire. Repository could also encrypt. Rick would like to
    leave it, with the understanding that we may remove it during interop.
    If we removed, then we may more easily align with PDF/A (see below).
    Internet fax also doesn't have encryption. Should we boot for the first
    version and re-evaluate in next version? Removing it would improve
    interoperability. Pull PKI, requires too much infrastructure. Standard
    doesn't require a public key, but does require MD5 hash, RC4 (RSA
    library).

    Right now we are going to remove encryption, and leave for future
    version.

                    5) Sender-URI Stamps. The format will provide an
    indirect link to the image of the stamp in the header of the document.
    Must be visible on at least the first page, recommended that if on more
    than one page SHOULD be cached. Optional in PDF/is and required in
    IPPFax. Change the name to "Originator identifier image".

                    6) Coloring - Make attribute coloring optional.
            7) Document review: issues.

            8) PDF/A: what is it? Adobe wants to converge PDF/is and this
    effort. It is archiving for National Archive, Gov docs. Rick will keep
    an eye on the effort. As PDF/A is currently written (a very early
    draft), we have the following incompatibilities:
        'Interpolate' must be FALSE (we require TRUE).
        DSigs are not allowed.
        PPK encryption is not allowed.
        Std encryption is not allowed.

            

                    ToDo:
                    1) Walk through references section and split into
    Normative-v-Informative
                             2) Keywords for Digital Signature types
                            3) Keywords for PDF types.
                    OpenIssues:
    1) IP issues
    2) Should we remove Encryption?

                    -----Original Message-----
                    From: Gail Songer
                    Sent: Friday, March 14, 2003 12:28 PM
                    To: ifx@pwg.org
                    Subject: IFX> Conf Call Summary

                    Next meeting will be Friday March 21 at 10am Pacific.
                     
                     
                    Topics for March 14, 2003:
                    1) Media size. What limitations do we want to place on
    image width and scaling?
                    Resolution: IPPFax: Paper size is unbounded in PFD/is.
    The Receiver MAY scale down at most 10% (PDF/is may prohibit this
    scaling), overflow to another page, or truncate. If the Receiver does
    truncate then it must notify the Receiving user. The Receiving user
    MUST be able to support A4/Letter at a minimum.
                     
                    Crop boxes SHOULD be used when the producer knows that
    the imaginable region is less than media size. If the crop box is the
    union of lesser size of Letter and A4 minus of inch, then the producer
    can be sure that the majority of consumers can print the image.
    However, this does mean that there is the possibly that data may lost.
                     
                    2) Page order. If the Producing device scans pages in a
    non-sequential order (all page fronts first, then page backs, for
    example), how do we want to indicate this (if at all) in the Document?
    Resolution: Add a new keyword to the beginning of the PDF/is which would
    allow the Consumer to modify its behavior. For example, if the Producer
    scans all the fronts and then all backs, the keyword would allow the
    Consumer to print in simplex (thereby allowing the User to reorder) or
    prompt the user to reinsert the stack, upside down, so that the Consumer
    can print to the back of the previously imaged pages. Each Page object
    will indicate which page this object represents.
                    3) Rob: For today's meeting, I would like to add PDF/is
    "structuring" to the agenda. The 's' in PDF/is means that all the
    objects needed to image a page come together in the file, between the
    page object for one page and the page object for the next. Beyond that,
    there is the exact order of the resource, content, image, etc. objects
    for the page. The current draft has a proposal, which I would like to
    discuss from the standpoint of expectations of writer and reader
    behavior. (Rob: can you please send your issues so that we many ponder
    the implications)
                    4) Sender-URI Stamps.
                    5) Coloring of attributes based on compression.
    (Resolutions)
                     
                    Kari's issue: Resolution: Length SHOULD be before the
    image. Consumer MUST be able to able to accept in either order. If the
    length is after the image, then must add the ID key from the file
    trailer as a comment after the length. Similar to mime methodology of
    determining end of include. (This is only an issue when reading a doc
    that is up-version and a new image format is unknown)
                     
                    ToDo: Walk through references section and split into
    Normative-v-Informative
                     
                    OpenIssues: IP issues
                     
                                    -----Original Message-----
                                    From: Gail Songer
                                    Sent: Thursday, March 06, 2003 3:51 PM
                                    To: ifx@pwg.org
                                    Subject: IFX> Conf Call Summary
                                     
                                    Next meeting is Friday March 14 at 10am
                                    Summary:
                                    Media Sizes supported. Width:
    Intersection of A4 and letter. Clip box inch in from each side. If
    won't fit on renderer's page, can scale image (require isomorphic
    scaling) and must notify the receiving user. --- What about length?
    In the Feb 25 call we had pondered not bounding the length of a page an
    allowing the device to split the image across pages.
                                    Resolution: Require a min/max?
                                                    In the data - min and
    max in the data stream, not discrete values, but ranges are ok. 300 pdi
    min. 1200 max.
                                                    On the output device -
    300 min. No maximum.
                                                    Image must be +- a point
    of the original size. (not per inch, per object)
                                    Required ColorSpace(s) - Require the
    device to support sRGB and gray gama 2.2; the sender can pick either of
    the two but MUST include the profile in the pdf/is data stream
                                     
                                    Only thing left to negotiate is buffer
    size....Just pick a size and then not negotiate. Put a stake at 4meg and
    turn during interop.. Remove memory size attribute
                                     
                                    Still open:
                                                Sender-URI Stamps.
                                          Coloring of attributes based on
    compression. (Resolutions)
                                    ToDo:
                                          Walk through references section
    and split into Normative-v-Informative
                                     
                                    -----Original Message-----
                                    From: Gail Songer
                                    Sent: Tuesday, February 25, 2003 1:01 PM
                                    To: 'ifx@pwg.org'
                                    Subject: Conf Call Summary
                                    Today's Conference Call Summary:
                                     
                                    Drop Flate from list of
    pdfis-compressions-supported (this used to be pdfis-profiles-supported)
                                    Make Masking mandatory for the receiver.
                                    Require both the sender and the receiver
    to support and use Banding. Drop support for Tiling.
                                    Color-space will be ICC with only the
    sRGP color profile. A pdfis device wouldn't have to process the
    profile, but the inclusion of the profile in the datastream would allow
    a PDF reader to process the document.
                                     
                                    Coloring by pdfis compression schemes:
                                                No longer need the following
    attributes:
                                    pdfis-compressions-supported (all
    compressions are required)
                                    pdfis-color-spaces-supported (only one
    colorspace)
                                    pdfis-data-encryption-supported
    (encryption types do not very based on compression)
                                    pdfis-cache-size-k-octets-supported (we
    will just pick a single required number)
                                    pdfis-orientation-supported - all images
    will be in landscape.
                                     
                                    Still Open:
                                                Media Sizes supported.
    Width: Intersection of A4 and letter. Clip box inch in from each side.
    If won't fit in renderer, can scale image (required isomorphic scaling)
    and must notifiy the receiving user.
                                                Resolution: Require a
    min/max?
                                                    In the data - min and
    max in the data stream, not discrete values, but ranges or ok. 300 pdi
    min. 1200 max.
                                                    On the output device -
    300 min. No maximum.
                                                    Image must be +- a point
    of the original size. (not per inch, per object)
                                                Sender-URI Stamps.
                                          Coloring of attributes based on
    compression. (Resolutions)
                                          Required ColorSpace(s) - sRGB and
    gray gama 2.2
                                     
                                    Only thing left to negotiate is buffer
    size....Just pick a size and then not negotiate 4meg. No memory size
    attribute
                                    ToDo:
                                          Walk through references section
    and split into Normative-v-Informative
                                     
                                     
                                     



    This archive was generated by hypermail 2b29 : Fri Mar 21 2003 - 15:45:35 EST