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;
  • 3
    What OS are you using? In Mac OS X I have found that "printing" a colour PDF to a grayscale PDF using the Quartz filter works well which corresponds to your second approach. If you post your gs command option I will compare the results of gs to Quartz in the grayscale conversion.
    – mforbes
    Commented Jan 13, 2013 at 22:42
  • @mforbes Done. I use linux and I would divert from gs only in a case of absolute need, which doesn't seem to be the case now.
    – yo'
    Commented Jan 13, 2013 at 23:17
  • I don't use ps but I have several colored text and figures created with tikz. I tried the pdflatex+gs conversion you posted and saw some blurred, gray text in place of the colored ones. There are no noticeable blurriness in the figures though.
    – hpesoj626
    Commented Jan 14, 2013 at 3:27
  • 1
    Iff your target is paper: Leave the colour conversion to the printing house: They should have professional software that does the right thing - and they know their equipment. Commented Apr 10, 2013 at 21:58
  • @MartinSchröder I'm the typesetter of the printing house, but ... how to say ... I'm the one to care, not they, they'd refuse it if it contained colour :-/
    – yo'
    Commented Apr 11, 2013 at 9:21

2 Answers 2


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:


Do a preflight check on a figure:


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.

  • pdftex (and luatex) don't do any processing of included pdfs - they are copied as-is into the resulting pdfs. Commented Apr 10, 2013 at 21:59

I suspect that one could get problems with the colorspaces the pdf's use. I'm really not an expert on this, but you might want to have a look at


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .