I don't think there is any concern about the 'PDF' trademark. Just look
at the following ISO specifications:
PDF/X-1a : ISO 15930-1
PDF/X-3 : ISO 15930-3
PDF/X Guidelines : 15929
PDF/X-2 : ISO 15930-2 (Not yet released)
None of these documents have had any trouble.
I don't think the name 'PDF' is even copyrighted.... See the copyright
statement at the beginning of the PDF reference. There is no mention of
'PDF' or 'Portable Document Format' as being copyrighted.
I can look into this further if you feel it's absolutely necessary.
-Rick
> -----Original Message-----
> From: don@lexmark.com [mailto:don@lexmark.com]
> Sent: Friday, November 15, 2002 11:24 AM
> To: Rick Seeler
> Cc: ifx@pwg.org
> Subject: RE: IFX> New Orleans Minutes
> Importance: High
>
>
>
> 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 : Fri Nov 15 2002 - 14:42:54 EST