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 ' (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 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 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 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 photo? 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 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 (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? 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 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