9

I use a print-on-demand company (lulu.com) that has always been picky and inconsistent about the PDF files they accept. I'm giving them files produced by pdftex. They use various subcontractors to fill orders (e.g., a Spanish one for European orders), and the subcontractors use different hardware and software. The result is that a book will print 100 times over a period of years, and then one day a certain subcontractor will try to print it, it will fail, and lulu will make the book unavailable for several days until they'll allow me to upload the same PDF file again -- which will then work fine for the next n orders. Recently they have gotten better about at least reporting what the specific error is. For the first time, they've sent me a screenshot from PitStop Pro, reading: "critical failures. failure (critical parser failure: XObject resource missing) occurred during Select all (6x on pages 243-244)." Lulu also says, "Usually this means there is some corruption int he file that might cause an issue. While the book has printed one other time, this issue makes the file unstable and could cause the file to continue to print sometimes and not others."

PitStop Pro is $800 proprietary software that doesn't run on the OS that I use (linux), so buying it isn't an option for me. Even if I bought it and could run it, this error message wouldn't help me to fix the problem. I've tried preflighting the book using open-source software as follows:

qpdf --check genrel_lulu_failed.pdf 
gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=b.pdf genrel_lulu_failed.pdf

Neither qpdf's parser not GhostScript's has any problem with the file, which was output by pdftex. Pdffonts reports that all fonts are embedded, none are subsetted, and none are multiply embedded.

The two pages referred to in the error message contain pdf figures output by inkscape. The figures aren't anything huge that would be expected to crash a parser due to a lack of memory. I have several hundred existing figures in various books that were all done with inkscape.

If anyone cares to take a look, here is the book: http://www.lightandmatter.com/lulu_stackexchange/book.pdf

Lulu says there are commercial services that will fix my file, but I suspect that those services would say, "OK, first give us your MS Word file..."

Does anyone have any suggestions for how to deal with this problem?

  • 3
    I can't answer how to fix it, but I can tell you that Adobe X Acrobat Professional 10.1.4 preflight tool agrees that there are syntax errors (missing XObjects) on PDF pages 243, 244 (book pages 245,246). Acrobat is proprietary, but much less than $800, and usually you can get academic or other discounts to push it down to less than $100, or it may be site-licensed by your employer... The missing objects are color spaces and graphics states, amongst other things. I can run preflight on the raw inkscape pdfs for you to see if it is an inkscape bug or a problem with pdftex's embedding. – Lev Bishop Sep 06 '12 at 04:03
  • Looks like a nice book! If I may venture a suggestion about design, I think the book will look nicer if section numbers were typeset outside the main body into the margin, especially because they're already in gray. – lhf Sep 06 '12 at 11:10
  • @Lev Bishop: Thanks very much. That's much more specific info than I had before. Unfortunately I can't run Acrobat Pro because I don't own a Windows or Mac machine. I've put the two pdf files here: http://lightandmatter.com/lulu_stackexchange/ If you could test them for me, that would be great. –  Sep 06 '12 at 20:13
  • @BenCrowell No errors with those files. If you want to try to bisect down to a minimal test case I can help you with that on chat http://chat.stackexchange.com/ – Lev Bishop Sep 06 '12 at 20:30
  • The pdf is useless if you want us to detect a bug in pdfTeX: Please upload a PDF of page 243 or 244 finally produced with pdfTeX somwehere. – Martin Schröder Sep 06 '12 at 21:32
  • 1
    @MartinSchröder: Good point. I used pdftk to strip the cover page off of that one, so it's really pdftk output, not pdftex output. The direct output from pdftex is this file: http://lightandmatter.com/lulu_stackexchange/book_pdftex.pdf –  Sep 06 '12 at 21:42
  • @Lev Bishop: That would be great. This weekend I will try to produce a minimal example of pdftex output that includes those two figures. Or if you check the output that wasn't post-processed through pdftk and find that it doesn't have the error, then we know it's a pdftk bug. –  Sep 06 '12 at 21:42
  • 1
    @BenCrowell: Iff the problem is on the page numbered 247 in the book, I fear the problem is with the inclusion of ./ch08/figs/cavendish.pdf and most likely with page transparencies. You could try to convert that figure to PDF 1.3. Updating to the latest version of pdfTeX (from TeXLive 2012) may also help. – Martin Schröder Sep 06 '12 at 21:57
  • If the problem is with transparency, then is the following workaround likely to work? I have hundreds of these svg figures. I can easily detect which ones (maybe 10%) use transparency, because they contain strings like this: "fill-opacity:0.50993401;". I can write a script that will detect these, and invoke inkscape's command-line interface to render them as png rather than pdf. (I can't use Adobe software to convert the figures to PDF 1.3, because I run linux. The release of ubuntu I'm running is currently at pdftex 1.40.10, and upgrading would be inconvenient.) –  Sep 06 '12 at 22:54
  • 1
    @BenCrowell, no error with book_pdftex.pdf so looks like a pdftk error. On the other hand, the output of pdftk book_pdftex.pdf cat 3-end output book_pdftex_nocover.pdf also has no syntax error, so not sure what to make of this... – Lev Bishop Sep 07 '12 at 14:06
  • 1
    However, the output of running book_pdftex.pdf through gswin32c -q -dNOPAUSE -dBATCH -dSAFER -sOutputFile=ll3.pdf -dCompatibilityLevel=1.5 -sDEVICE=pdfwrite book_pdftex.pdf does show the syntax errors, so it seems a ghostscript error. – Lev Bishop Sep 07 '12 at 14:22
  • 2
    Ghostscript bug opened here: http://bugs.ghostscript.com/show_bug.cgi?id=693322 – Lev Bishop Sep 07 '12 at 16:06
  • Aha, that makes sense! I was doing the following to eliminate complaints from lulu about missing fonts: gs -q -dCompatibilityLevel=1.4 -dSubsetFonts=false -dPDFSETTINGS=/printer -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=genrel_lulu.pdf temp.pdf -c '.setpdfwrite' But in fact I found a different mechanism to accomplish that, so I can just stop filtering through ghostscript. –  Sep 07 '12 at 18:04

0 Answers0