If there is no problem with PDF in the title, I prefer having PDF in the
title, since PDF is so widely recognized.
Since ISO has PDF in the various PDF subsets, I would think that the
IEEE-ISTO could too.
Tom
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Friday, November 15, 2002 11:24
To: Rick Seeler
Cc: ifx@pwg.org
Subject: RE: IFX> New Orleans Minutes
Rick, et al:
I would really like to get rid of the "PDF" portion of the name to
elimination ANY problems now or in the future with regards to Adobe's
trademark.
Perhaps others can suggest alternative names but some ideas might include:
Streamable Image Format for Printing (SIFP)
Streaming Image Objects for Printing (SIOP)
Streamable Semblance Image (SSI)
Streamed Semblance Image Format (SSIF)
Of course there's the ole'
Printable Image Semblance Stream (I'll not acronymize that one.)
**********************************************
Don Wright don@lexmark.com
Member, IEEE SA Standards Board
PatCom Chair, SCC Liaison
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
"Rick Seeler" <rseeler@adobe.com>@pwg.org on 11/15/2002 12:45:15 PM
Sent by: owner-ifx@pwg.org
To: <ifx@pwg.org>
cc:
Subject: RE: IFX> New Orleans Minutes
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@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'
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.
This archive was generated by hypermail 2b29 : Tue Nov 19 2002 - 18:28:19 EST