Everyone,
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?
-Rick
> -----Original Message-----
> From: owner-ifx at pwg.org [mailto:owner-ifx at pwg.org] On Behalf
> Of Gail Songer
> Sent: Friday, November 15, 2002 9:16 AM
> To: ifx at 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'
object.
>> 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
required.
>> 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.