IFX Mail Archive: RE: IFX> New Orleans Minutes

IFX Mail Archive: RE: IFX> New Orleans Minutes

RE: IFX> New Orleans Minutes

From: Rick Seeler (rseeler@adobe.com)
Date: Fri Nov 15 2002 - 12:45:15 EST

  • Next message: don@lexmark.com: "RE: IFX> New Orleans Minutes"


    The items noted with '*****' have been integrated into the 0.3 revision
    of the PDFax specification that will be released soon.

    I want to change the name of the 'PDFax' specification to 'PDF/is' (PDF-
    Image, Streamable) to remove the 'FAX' connection. Does anyone have any
    objection to this change?


    > -----Original Message-----
    > From: owner-ifx@pwg.org [mailto:owner-ifx@pwg.org] On Behalf
    > Of Gail Songer
    > Sent: Friday, November 15, 2002 9:16 AM
    > To: ifx@pwg.org
    > Subject: IFX> New Orleans Minutes
    > Hi All,
    > Here are the minutes from New Orleans
    > Gail
    > 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
    > Agenda:
    > Morning:
    > Adobe's IP statement for the PWG (it's just awaiting final CEO
    > approval)
    > Full review of the current PDFax spec.
    > Change review of the IPPFAX spec.
    > Afternoon:
    > Review major point that were discussed in the morning
    > session, for the callers
    > Quickly review the changes to the PDFax spec that I made
    > since revision 0.2
    > (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:
    > image-only
    > streamable
    > supports encryption
    > Lee Farrell asked whether Adobe is willing to allow us to use
    > the name "PDF Fax"
    > 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 ISTO
    > Rick started going through the PDFax spec
    > After presenting terminology (chapter 2), skipped to
    > section 4.3 to give overview
    > 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 RAND
    > 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 'Single Image' profile has been moved out of the Image
    profiles specifier.

    > 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

    ***** All profiles now have readable names.

    > 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 changes
    > 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

    ***** The table has been redesigned.

    > Rick went through PDF Field information in section 3.3
    > The only new object is the 'PDFax' object
    > The 'PDFax' name might change

    ***** The object is now called the 'Profiles' object.

    > 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

    ***** Version numbers are now the first two values in the 'Profiles'

    > 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 photo?
    > Can it be streamed?
    > Do we need to start to use banding?
    > Sounds like it

    ***** Working on this now -- not sure if I will be successful.

    > 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

    ***** Spec has been changed to require Profile 4 (See T.89 for
    definition). Can anyone see a reason why we should support other
    Profiles that are defined in T.89?

    > 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 IP
    > 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

    ***** PDF already limits the implementation to the JPEG baseline or
    Progressive. I added a requirement not to use Progressive JPEG and that
    all images must not be interlaced.

    > (At this point, teleconference began.
    > New participants: Ira McDonald, Tom Hastings, Rob Buckley, Lloyd
    > McIntyre)
    > 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 this
    > Should we specify a minimum amount of memory that any IPP
    > Fax implementation must have?

    ***** For JBIG2, I put in a requirement for 'Level 2' memory (2
    Megabytes). See T.89 for a description.
    ***** For JPEG, I put in a memory requirement that is spelled out in a
    PostScript DCTDecode document.

    > 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 page
    > 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

    ***** In progress.

    > 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

    ***** JPEG is required if Color or Gray scale is supported, but an
    implementer may only implement bi-level. In that case, JPEG is not

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

    ***** I took a crack at this. See 0.3 of the spec for the details, once
    I release it.

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