I just found out that my message that I sent out yesterday did not get
posted. (Probably because I had an attachment). Here it is again...
IFXers,
The new version of the PDF/is specification (0.5) is available at:
ftp://pwg.org/pub/pwg/QUALDOCS/pwg-ifx-pdfis-P05-021219.pdf and
ftp://pwg.org/pub/pwg/QUALDOCS/pwg-ifx-pdfis-P05-021219-rev.pdf
To answer comments made by Robert Buckley and others (privately), I have
made the following changes to the PDF/is specification:
1) The terms 'Creator' and 'Renderer' have been replaced with 'Producer' and
'Consumer' to match terminology used in the PDF Reference.
2) Support for 'Flate', 'JPEG', and 'Masking' are now considered 'required'
by the Consumer. This was changed in the interest of creating a format that
has fewer options.
3) Support for 'CalGray', and 'CalRGB' were dropped from the spec in favor
of 'DeviceGray' and 'DeviceRGB' color spaces.
4) 'DeviceRGB' is defined to represent sRGB.
5) 'DeviceRGB', 'DeviceGray' and 'Lab' color spaces are now 'required' by
the Consumer.
6) The 'Dependency' column of Table 3-5 has been removed since no features
depend on any other features as the spec is now written.
7) Support for JBIG2 Profile 1 (See T.89) has been added to the JBIG2
support in addition to Profile 4.
8) Objects in the 'cache hold' can now be 'freed' in the middle of the
'Content Stream'.
9) 'Banding' has now been upgraded to full 'Tiling' support.
10) 'Adobe.PPKLite' has been removed as the required 'Filter' name for
encryption and Dsig.
11) Various other minor changes -- See notes in PDF at:
ftp://pwg.org/pub/pwg/QUALDOCS/Reply-Xerox_PDFis_0-4_CommentsVer.2.pdf
---------------------------
Current outstanding issues:
1) In the interest of blind-interchange, should JBIG2 rendering support be
required of all consumers? The only other 'Optional' features in the spec,
as it now stands are:
A) Standard Encryption.
B) PPK Encryption.
C) Digital Signaturing.
Here are my feelings on each of these:
A - May require licensing of RC4 encryption software. Standard
encryption requires a target device that can query and take a password as
input: this may not be practical for all types of devices. This should
remain an option.
B - May require licensing of encryption software. PPK encryption
requires that the consumer have a public key that the producer can retrieve
via IPP (or some other mechanism). A 'profile' isn't necessary for this
feature: if the producer is unable to get the consumer's public key, the
producer will not be able to use this feature.
C - A Digital Signature may be applied to any document. The
consumer doesn't have to validate the signature if they don't wish to, or
are not able to do so.
2) Should we "hard code" a minimum buffer size for the memory cache value
(Section 3.3.1.1.4) instead of making this another parameter?
3) A proposal from Xerox that I'm not sure I can answer right now: "General
comment about DID and Annotation fields, and the possibility of using one or
the other as a mechanism for including a "fax transmit header" or sender-uri
value, per Sec. 9.5 in IPPFAX 1.0 Protocol Draft. Right now the
recommendation is to burn it into the image data, but the DID or Annotation
field could be used for this attribute value--consider text to this effect
in 3.3.19 or 3.3.17."
--------------------
Rick Seeler
Technical Lead - Strategic Technology Team
Print Workflow Products Group
Adobe Systems Incorporated
Mailstop E13
321 Park Ave.
San Jose, CA 95110
rseeler@adobe.com
V. (408) 536-4393
F. (408) 537-8077
This archive was generated by hypermail 2b29 : Fri Dec 20 2002 - 13:05:26 EST