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