IFX Mail Archive: IFX> New Orleans Minutes

IFX Mail Archive: IFX> New Orleans Minutes

IFX> New Orleans Minutes

From: Gail Songer (gsonger@peerless.com)
Date: Fri Nov 15 2002 - 12:15:35 EST

  • Next message: Rick Seeler: "RE: IFX> New Orleans Minutes"

    Hi All,

    Here are the minutes from New Orleans


    Official minutes

    IPP Fax meeting, New Orleans 11/8/02

    Meeting led by Gail Songer, Peerless, and Rick Seeler, Adobe
    Minutes taken by Dennis Carney

        Adobe's IP statement for the PWG (it's just awaiting final CEO
        Full review of the current PDFax spec.
        Change review of the IPPFAX spec.

        Review major point that were discussed in the morning session, for the
        Quickly review the changes to the PDFax spec that I made since revision
          (there are just a few)
        Take new issues/concerns from the callers
        Review changes that will be made to the specs for the next revision.

    Rick reported that Adobe will have an official Intellectual Property
    statement for the
      PWG very soon

    PDFax is PDF with:
      supports encryption

    Lee Farrell asked whether Adobe is willing to allow us to use the name "PDF
      Is it a good idea for the PWG to use a trademarked name like "PDF"?
      Rick will look into it at Adobe, and Harry will look into it with the

    Rick started going through the PDFax spec
      After presenting terminology (chapter 2), skipped to section 4.3 to give
        of the file layout
      He also showed a sample PDFax file, and went through it

    He explained how the printer could use the information to quickly go
    through the file
      and determine what pieces of the file it needed to cache

    New keyword '/ObjectCache' that says that some object should not be
    discarded from cache
      until specifically told otherwise
      Then '/ObjectCache <array>' (e.g. /ObjectCache [3 0 R]) says to release
    the objects in
        the arrray; that is, they're no longer needed to be cached
      This is needed because we're making this streamable

    Harry was asked about JBIG2 IP issue
      He said his answer so far in IBM is that IBM will license any IP under
      Rick said that Adobe somehow did their own JBIG2 royalty-free
      As it turns out, JBIG2 (profile T) is optional in PDF Fax

    Rick went through image profiles overview (section 3.1.1)
      A new profile in PDF Fax is 'P': single image
        This says that the file contains only one single page
        This is a quick way for a reader to know that there is exactly one
    image, on one page

    The issue of the names of the profiles came up
      Why 'T' vs. 'JBIG2'?
      Should we change the names of the profiles?
      It sounds like Rick is going to change them

    Rick presented the security profiles (section 3.1.2)
      He pointed out that the Digital Signature is based on checksums, so the
    printer will
        not be able to know whether a document has been modified or not until
    it has the
        entire document
        Lee Farrell wondered whether that makes the Digital Signature of
    limited use
        Should we have it in our spec if our design point is printers that
    can't look at the
          entire document before starting?
        Harry pointed out that this feature would seem to be useful to
    lawyers--for faxing
          contracts, for example

    Rick presented the color profiles (section 3.1.3)
      Issue: What is justification for final paragraph in section 3.1.3
      Rick said it was such things should be compressed, and the only
    compression we have
        in PDFax is Flate

    The issue came up about how these profiles are related to the same profiles
    in base PDF
      All color profiles are exactly the same as PDF, but PDF calls it
    something different
      Some of the image profiles are the same as PDF
      But all changes from PDF are simply limiting PDF; no additions, no

    Looking at table 3-4
      There was some confusion about what the Profile column meant
      It basically is the short name profile for the filter in column one
      Rick is going to get rid of this column
        Maybe put the profile name in parentheses in column 1

    Rick went through PDF Field information in section 3.3
      The only new object is the 'PDFax' object
        The 'PDFax' name might change
          Adobe has official name registry
        Rick added a new keys in this object: Root, Encrypt, Info, NextPage
          Root, Info, and NextPage are to make things easier to parse

    How to provide for new vendor-specific profiles to be added?
      Add a new key
      So bits are reserved for future PWG use

    What about extensibility of PDFax value (the [IMAGES SECURITY ...] value)?
      Spec should indicate implementations cannot add entries to this list
      And that new unknown entries at the end should be ignored, to make it
    possible for
        the PWG to add entries in later version

    Rick also added MAJ_VER and MIN_VER to the list, at the front

    Discussed MEMORY
      There is a mechanism external to PDFax (it is in the IPPFAX spec) for a
    client to
        ask the Printer how much memory they have
      The PDFax doc is created with some assumption of how much memory a
    renderer must
        have to be able to render the document
      What happens if a printer says it has 4Mb, but a PDFax creator has a 6Mb
        Can it be streamed?
      Do we need to start to use banding?
        Sounds like it
      We'll still need the MEMORY value to specify how much memory is necessary
    *in addition
        to* the amount needed for the page data
      We'll bring up this issue in the teleconference this afternoon

    Going through filter sections (section 3.3.2-3.3.x)
      In JBIG2 case, do we want to force the renderer to do all profiles?
      Or say that we are only doing some specific profiles (see JBIG2 spec
    (ISO/IEC 14492),
        Annex F, for description of profiles)?
      Conclusion: We'll probably specify some profiles, maybe profile 3
        We'll mention this during the teleconference this afternoon

      Might there be a difference in IP issues for different profiles?
        There were a number of patents listed in the JBIG2 spec
          Harry is going to look into IBM IP issues in this area
      In any case, we do not believe that there will be any major problems with
        JBIG2 is expected to stay in the spec in any case

      JPEG (DCTDecode filter)
        Same question: do we want to limit; is there IP?
        For this, should look at XHTML-Print spec, appendix A

    (At this point, teleconference began.
      New participants: Ira McDonald, Tom Hastings, Rob Buckley, Lloyd

    Bringing up a few of the issues from above:
      MEMORY issue
        How does Creator make sure it doesn't exceed memory size that Renderer
    can handle?
          Should Creator degrade the picture (for example) to make it fit?
            Some thought the Creator must ask the user for permission to do
        Should we specify a minimum amount of memory that any IPP Fax
    implementation must have?
        How about just saying that the renderer must have enough memory to
    handle one
          uncompressed page?
        We figured out that we were actually discussing memory for page data,
    not memory
          for cache
        For cache, if the sender is going to have more cache than the receiver
    can handle, it
          should just change it so it uses less cache

        For the issue of page data memory, there was much discussion, but no
    clear conclusion,
          I don't believe
        This needs to be looked at further

        What about banding? Do you want to specify that in our spec?
          What about feed-direction issue: scan long-edge but print short-edge
          Yes, banding won't work for this, so banding is not the panacea
          So Rick will add support for banding into the PDF Fax spec
          The bands must not move back up the page, and must never overlap
          This support will also include ability to put arbitrary objects onto
    a page,
            then allowing the writer to specify that what came before was a
    band, thus
            telling the rendered it can go ahead and render that much of the
          This support will also include orientation: short-edge or long-edge
          So support for banding would be required by both sender and receiver?
          Conclusion: Rick is going to look into this and write something up

      Another question: Should JPEG be required?
        Some say yes, to raise the bar
        XHTML-Print requires JPEG
        Same issue came up with Intellectual Property status of JPEG
        No hard conclusion

      Do we want to specify JBIG2 profiles?
        Didn't have time for this

    This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 12:13:47 EST