This is related to:

... but a bit more specific here: say I have an RGB PDF, where the text color is "rich black" (R:0 G:0 B:0 gone to C:100 M:100 Y:100 K:100), and diverse images and vector graphics.

I would like to convert this to a CMYK PDF, using a free command line tool (so it is batch scriptable under Linux), which

  • has contents only in the black (K) channel:
    • Preserves vector graphics (+ text glyphs) - colors become grayscale in black (K) channel only
    • Images get converted to grayscale in black (K) channel only

Thanks in advance for any answers,
Cheers!

share|improve this question

feedback

3 Answers

up vote 2 down vote accepted

As hinted in my comment to @Mark Storer, it turns out that forcing a gray print only on the K plate in CMYK, may not be so trivial ... I guess it depends much on what is being used as "preflight" preview device - for Linux, the only thing I can find is ghostscript with tiffsep, which is what I use for 'sanity check' regarding CMYK separations.

Anyways, I got a lot of help in this thread on comp.lang.postscript:

... and one workflow that works for me is:

  • Convert PDF to PS using ghostscript's ps2write
  • Use ghostscript to convert this PS back to PDF, while executing replacement functions in HackRGB-cmyk-inv.ps
  • Use ghostscript's tiffsep to check actual separations

 

In respect to, say, this PDF generated by OpenOffice: blah-slide.pdf, the command lines would be:

# PDF to PS using `ps2write` device of `ghostscript`
gs \
   -dNOPAUSE \
   -dBATCH \
   -sDEVICE=ps2write \
   -sOutputFile=./blah-slide-gsps2w.ps \
    ./blah-slide.pdf 

# PS to PDF using replacement function in HackRGB-cmyk-inv.ps
gs \
   -dNOPAUSE \
   -dBATCH \
   -sDEVICE=pdfwrite \
   -sOutputFile=./blah-slide-hackRGB-cmyk-inv.pdf \
    ./HackRGB-cmyk-inv.ps \
    ./blah-slide-gsps2w.ps

# check separations
gs \
   -dNOPAUSE \
   -dBATCH \
   -dSAFER \
   -sDEVICE=tiffsep \
   -dFirstPage=1 \
   -dLastPage=1 \
   -sOutputFile=p%02d.tif \
    blah-slide-hackRGB-cmyk-inv.pdf \
\
&& eog p01.tif 2>/dev/null 

This should only work on RGB values where R=G=B (and hopefully grayscale values), and only on text colors, and it also flattens text information - but it should be possible to confirm via tiffsep that the text indeed ends up only on the K plate.

As mentioned in the newsgroup post, this is not extensively tested, but looks promising so far...
Cheers!

share|improve this answer
feedback

I suggest you convert the PDF using GS twice. Once to a Shades Of Gray colorspace, and then to CMYK.

I'm not sure it'll work, but I'd be a bit surprised if it didn't. G->CMYK sounds like a brain-dead X -> 0 0 0 X conversion. At least if you stick to "device gray" and "device CMYK" instead of some calibrated color space that'll tweak things this way and that.

share|improve this answer
Hi @Mark Storer, thanks for the answer! I guess, demonstrating that the G->CMYK conversions could be a matter of which device renders the final display; I use gs with tiffsep for (I guess) "preflight", and usually, just a RGB->G->CMYK will show text black on all four plates, just like when viewing the original RGB "preflight". However, I got some answers on comp.lang.postscript, which I'm going to post about next... – sdaau Jun 9 '11 at 12:34
feedback

As an improvement to sdaau's great answer, I can recommend using pdftops from xpdf for converting pdf to ps, instead of ghostscript ps2write, because the latter e.g. causes the font to become staircasey, and is said to not preserve the original pdf accurately. Compare by zooming into text areas of the resulting pdfs.

share|improve this answer
Many thanks for that answer, @Ole - great to have an alternative here... Cheers! – sdaau Feb 3 at 8:49
feedback

Your Answer

 
or
required, but never shown
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.