[pdftex] Incorrect pdf produced from a single correct pdf file

[George N. White III]

On Sat, Oct 4, 2008 at 4:09 PM, Olivier Cailloux <mlsmg at ulb.ac.be> wrote:
> Thank you to all those who responded so quickly. I am still wondering is
> someone can explain why the given tex file does not work for me when it
> does work for others...
>
> A few comments, concatenating all relevant replies.
>
> Martin Schröder asks me why not doing it in LaTeX: as Andreas said, I am
> indeed trying to merge the files using LaTeX (and I did not expect to
> start a pdfTeX vs LaTeX war!). But it did not work with the pdfpages
> package in LaTeX and I am trying to discover why. My post here is simply
> to try to boil the problem down to some more precise problem.
>
> The backslashes characters have been stripped from my post for an
> unknown reason, as John Culleton noticed. Naturally they were present
> when I compiled the tex file.
>
> Thank you also for the alternative suggested tex commands, but it won't
> help me as I am only trying to understand how come that the sample tex
> file does not work for me where it correctly works for others.
>
> Hartmut Henkel says that "the PDF in the attachment of your e-mail
> contains in object no. 1 a broken LZW stream (but the RMItd24.pdf is
> ok.). This can't be forced (easily) by macro programming, so it could be
> some bug in the old pdfTeX version or its xpdf library used for creating
> the PDF file. My current pdfTeX-1.50.0-alpha here doesn't produce a
> corrupted PDF."
>
> Very interesting remark. But I am still not convinced that this
> is a version problem, as Andreas tells me that my sample .tex file works
> for him on his system using the same pdftex and xpdf versions as I do
> (except that, looking closely, he has version 3.141592-1.40.3-2.2 where
> I have version 3.141592-1.40.3, what's this 2.2 behind?).

Using TeX Live 2007 as provided by Red Hat Fedora 8:

$ cat t
\pdfximage width .5\hsize{RMItd24.pdf}
\pdfrefximage\pdflastximage
\bye
$ pdftex t
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
 %&-line parsing enabled.
entering extended mode
(./t.tex [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./RMItd24.pdf>]
 ){/usr/share/texmf/fonts/enc/dvips/lm/lm-rep-cmrm.enc}</usr/share/texmf/fonts/
type1/public/lm/lmr10.pfb>
Output written on t.pdf (1 page, 25325 bytes).
Transcript written on t.log.
$ evince t.pdf
Error (684): Bad LZW stream - unexpected code
Error: Unknown operator 'Z'
Error (684): Bad LZW stream - unexpected code
Error: Unknown operator 'Z'
Error (684): Bad LZW stream - unexpected code
Error: Unknown operator 'Z'
Error (684): Bad LZW stream - unexpected code
Error: Unknown operator 'Z'

The page is blank except for the "1" at the bottom.  I also tried:
$ pdftex t
This is pdfTeXk, Version 3.141592-1.40.5 (Web2C 7.5.6)
 with the same outcome.

> I will try to report the problem on the Debian bug reporting system, as
> the problem probably is distribution specific. Please tell me if you are
> interested by the results.

If I do  epstopdf --outfile s.pdf RMItd24.pdf then the job works
with s.pdf.   The problem is not distribution-specific.   PDF is a
complex format and it is not surprising that some rarely used
construct would cause problems.  There have been some
changes in the PDF specifications where the original was
ambiguous, so you may not get the same PDF using current
Adobe tools (RMItd24.pdf was created with Adobe DIstiller 3.02).
One advantage of a PDF workflow is the availability of 3rd party
tools that can rewrite a problem pdf to something more
"mainstream".  Of course you need to check carefully that the
converted document is rendered correctly.

-- 
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia