[Tex/LaTex] Pros and cons: pdflatex+gs vs gs+pdflatex

colorghostscriptgraphicspdfpdftex

I need to be producing two versions of documents I deal with: colour and grayscale. Of course the real issue are images. I'm not the author of the documents nor the images, I'm only the typesetter.

  • So far I use the following quite complicated procedure that can be called gs+pdflatex:

    1. Convert all images to PDF (epstopdf, convert).
    2. Put them in sub directory figures/.
    3. Using gs (GhostScript) convert the images to grayscale to directory figuresbw/.
    4. By different \graphicspath{} control which ones will be used.
  • However, there is the other option that can be called pdflatex+gs:

    1. Don't care at all about image types, pathes etc.
    2. Run pdflatex to get the colour version.
    3. Using gs (GhostScript) convert the document to grayscale.

Obviously the second option is easier to perform, but I have a bad feeling that there must be some drawbacks. So the question: What are the drawbacks of using one option or the other?


My gs command:

nice gs \
  -sOutputFile=$outfile.pdf \
  -sDEVICE=pdfwrite \
  -sColorConversionStrategy=Gray \
  -dProcessColorModel=/DeviceGray \
  -dAutoRotatePages=/None \
  -dCompatibilityLevel=1.4 \
  $infile.pdf < /dev/null;

Best Answer

If I'm understanding the situation correctly, you're receiving a document with EPS figures from a customer, and you need to produce bulletproof color and grayscale PDFs which you will then pass on to a third-party to RIP. You may not have control over the software used for the RIP, so you want to do whatever will minimize the probability of problems.

You're using epstopdf to convert the figures to PDF, and epstopdf is simply a wrapper for gs. That means that your current workflow is actually gs+gs+pdflatex. Passing the same figure through gs twice in a row seems like a relatively safe thing to do. If the PDF code generated by gs is buggy, then the bug is presumably present after the first pass, and it's not so likely that any new bug will creep in on the second pass.

The gs+pdflatex+gs workflow sounds like a bad idea to me. I've had problems in the past where filtering pdflatex output through gs produced buggy pdf output, and the result was rejected by a RIP. The RIP was apparently correct to reject it, because the gs output was actually syntactically invalid. The bug was reported to the gs team, who responded by saying that they didn't care and wouldn't fix it: http://bugs.ghostscript.com/show_bug.cgi?id=693322

I would suggest that you do some preflight checking on the figures. It's safest if they use outlines rather than fonts. I've had frequent RIP problems with PDF figures that used transparency, so my current practice is that for any figure that uses transparency, I render it to a bitmap using pdftoppm and have pdflatex grab the bitmap. At 300 dpi they look quite good. Here are a couple of scripts I use to automate that process.

Render an SVG figure to PDF or PNG as appropriate:

http://www.lightandmatter.com/cgi-bin/gitweb.cgi?p=.git;a=blob;f=scripts/render_one_figure.pl

Do a preflight check on a figure:

http://www.lightandmatter.com/cgi-bin/gitweb.cgi?p=.git;a=blob;f=scripts/preflight_one_fig.pl

This is slightly different than what you want to do, since your source format is EPS rather than SVG, but I think you'll find that a lot of the preflight checks and conversion methods will also apply to you. Since we're both on linux, snippets you take from my code should work for you as well.

In general, I don't think pdflatex does any processing at all on PDF figures. It simply copies them into its output. That means that any syntax errors in the PDFs will also be present as syntax errors in the output of pdflatex. It also means that any fonts embedded in the PDFs will be embedded in pdflatex's output. For example, if there is a font in one of the figures whose license forbids redistribution, then that illegal font appears in your pdflatex output as well. It's a good idea to use the linux utility pdffonts on both the figures and the final output so you can see what's going on. For all these reasons, the safest approach of all would be to render every single figure as a bitmap.