Bill Allombert wrote:
> Honestly, unless you provide evidence that PS files that include invalid
> jpeg-encoded data are still in use, I am not going to include two new packages
> to support non-standard compliant data in Debian, and in any case, I doubt the
> FTP master would let me.
Makes sense. Currently ghostscript/README.Debian says:
GPL Ghostscript is linked against the shared IJG JPEG library (not a
statically linked local copy). Some valid PostScript and PDF files will
fail to parse due to some (old, presumably?) Adobe interpreters
violating the JPEG standard. More info at [bug#582521].
[bug#582521]: <http://bugs.debian.org/582521>
http://www.ghostscript.com/pipermail/gs-code-review/2002-March/002275.html
tells a slightly different story:
First, I have no doubt that at one time there were files in the
wild that exceeded the JPEG standard for the number of blocks in the
MCU. In fact, Adobe's tech note 5116 suggests that Adobe did come
across such implementations in their own interoperability testing
in 1991. This tech note also states that Adobe's implementation, at
least in some cases, will tolerate such out-of-spec JPEG streams.
That said, the PRLM3 states quite straightforwardly that the number
of blocks in the MCU must not exceed 10. The PRLM2 contains the same
condition, but attributes it to "the JPEG-proposed standard". Thus,
I believe that any PostScript file containing a non-compliant JPEG
stream can safely be considered invalid.
How likely are we to run across such invalid files? A note from Tom
Lane (author of libjpeg) states that he's never seen such a file, nor
has he recieved a bug report from anybody about the MCU issue:
http://remotesensing.org/lists/libtiff_archive/msg00355.html
Thus, I conclude that the chance of ordinary users running across a
problem with such files is nil.
So I do not even think that there are old Adobe interpreters involved
(despite what jpeglib.h says). Would it be enough to say something
like this?
On Debian systems, ghostscript is linked against the shared
IJG JPEG library, instead of using the patched local copy
bundled with the ghostscript source. The two versions of
the library behave identically except in two respects, both
concerning invalid JPEG streams:
- The bundled libjpeg fakes a valid component id when JPEG
streams include an SOF or SOS marker whose component
identifiers are not all distinct (see the description of
C_i in B.2.2 of the JPEG spec). The shared IJG JPEG
library produces artifacts (e.g., stripes) when presented
with such component ids.
http://bugs.ghostscript.com/show_bug.cgi?id=686980
- The bundled libjpeg is configured to accept up to 64 blocks
per MCU, instead of the limit of 10 blocks per MCU described
in the Postscript reference manual and JPEG standard.
According to lore and Adobe's tech note 5116, in 1991 Adobe
came across some files in the wild exceeding the standard
for blocks per MCU, and Adobe's implementation would
sometimes accept such streams.
If you come across a file triggering either of these
conditions, please let us know by reporting a bug against
the ghostscript package.
--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110806232954.ga4...@elie.gateway.2wire.net
