I am converting an RGB PDF to CMYK using the following command:
/usr/local/bin/gs -dSAFER -dBATCH -dNOPAUSE -dNOCACHE -sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK -sColorConversionStrategyForImages=CMYK \
-dProcessColorModel=/DeviceCMYK -dEncodeColorImages=false \
-dEncodeGrayImages=false -dEncodeMonoImages=false -sOutputFile=CMYK.PDF RGB.PDF
The resulting file is 100% CMYK, however anything that was 100% black in the RGB PDF is now:
C: 72%
M: 68%
Y: 67%
K: 89%
The result is that black is a slightly dark grey when really it should be black.
Is there anything I need to add to this command to ensure black remains as black during the conversion?
With the current version of pdfwrite you are restricted to the colour conversions in the software, and there is nothign you can do about this.
The colour management is undergoing serious revision, and the next release should make it possible to deal with this.
Examples of Ghostscript commands to convert PDF from sRGB or eciRGB_v2 to eciCMYK_v2 (FOGRA 59) while keeping black plain (K only), not rich (CMYK)
I managed to convert PDF file in RGB to CMYK while keeping RGB black #000000 plain K black, not rich CMYK black.
DeviceLink ICC had to be created from e.g. eciRGB_v2 (or sRGB, if your source is sRGB) profile to the appropriate CMYK profile using collink tool (from argyll package) with the "-f" attribute to hack the black colors.
Ghostscript is then called with a control file declaring use of the profile and its parameters.
Example of making the DeviceLink RGB to CMYK profile
collink -v -f eciRGB_v2.icc eciCMYK_v2.icc eciRGB_v2_to_eciCMYK_v2.icc
Example of a control file to map eciRGB_v2 to eciCMYK_v2
Image_RGB eciRGB_v2_to_eciCMYK_v2.icc 0 1 0
Graphic_RGB eciRGB_v2_to_eciCMYK_v2.icc 0 1 0
Text_RGB eciRGB_v2_to_eciCMYK_v2.icc 0 1 0
Sample ghostscript command to do the actual conversion
gs -o 2-output-cmyk-from-eciRGB.pdf \
-sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK \
-sSourceObjectICC=control-eciRGB_v2.txt \
1-input-rgb.pdf
Related
I used instructions from here to convert an RGB PDF to CMYK using Ghostscript, and it's mostly OK except all the blacks are "rich" - they use not just K but also CMY inks.
Is there a way to convert such that all blacks are "flat" and just use K?
This is the code I used:
gs \
-o test-cmyk.pdf \
-sDEVICE=pdfwrite \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sColorConversionStrategyForImages=CMYK \
test.pdf
Assuming your PDF file actually does use RGB (and not an ICC profile embedded in the PDF) then, in order to get R=G=B->C==M=Y=0, K=R, you need to set up a custom ICC profile link.
You'll need to tell Ghostscript to use a custom RGB profile in place of default_rgb.icc and a cuustom CMYK profile in place of default_cmyk.icc. You'll need to ensure that the mapping RGB->XYZ->CMYK results in pure K when R=G=B.
There's documentation in the Ghostscript 'doc' folder on the various colour management settings, but most of these will only be effective when rendering, not when outputting a PDF file. About the only things you can usefully alter when outputting PDF is the input and output profiles.
I'm trying to convert an RGB-pdf file created by Inkscape to a print ready cmyk-pdf using PSOcoated_v3.icc color profile. PDF generation works fine. However, I'd like to check for correct final colors, especially for the black. As I did not found any (free) tool to pick the cmyk color from the final pdf I thought as a first check I convert the RGB-pdf to cmyk-tiff and check the black value. Doing so using
gs -q -dBATCH -dSAFER -dNOPAUSE \
-sDEVICE=tiff32nc \
-sDefaultRGBProfile=sRGB2014.icc \
-dOverrideICC \
-sOutputICCProfile=PSOcoated_v3.icc \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sOutputFile=rgb.pdf \
cmyk.tiff
yields a cmyk black value of [0.83, 0.67, 0.51, 0.95]. Contrarily, when I use libcms2 to convert rgb (0,0,0) to cmyk I get [0.92, 0.64, 0.45, 0.96] which matches (almost) some information about the PSOcoated_v3.icc profile I found here. To confirmed that the source RGB-file black reads (0,0,0) I convert the RGB-pdf to an RGB-tiff and do find the black to be (0,0,0).
Am I missing something in the command of might this be a gs bug?
If I take an RGB color of [0,0,0] in sRGB color space and convert it to the CMYK value defined by the PSO coated v3 ICC profile in Photoshop (using Adobe ACE CMM in Photoshop), I get exactly the CMYK values you are seeing with gs, that is [0.83, 0.67, 0.51, 0.95].
That was using a relative colorimetric rendering intent with black point compensation enabled. Those are the settings that gs would be using for lcms by default.
I suspect that when you use libcms2, it is using a different rendering intent. For example, when I use the perceptual rendering intent with Adobe ACE I get [0.90, 0.64, 0.45, 0.96].
Note that you can specify with gs what rendering intent you want to use with
-dRenderIntent=0/1/2/3 . See https://ghostscript.com/doc/current/Use.htm#ICC_color_parameters for details.
I'm trying to add the capability to render LaTeX equations to a project I'm working on. To do so, I use XeLaTeX to create a PDF file, which I then render to a (transparent) 96dpi-PNG using Ghostscript.
I'd like to have the rendered LaTeX blend in with the rest of the text (which is rendered using standard .NET GDI+ methods, but that's off-topic), but I can't get a reliably "good" text rendering: the output always looks somehow blurry or otherwise "bad".
Example:
From left to right, the same (small) PDF rendered at 96dpi with Ghostscript, Photoshop, and TexWorks (which I understand uses Ghostscript internally).
The command I use to run Ghostscript is the following:
"C:/Program Files (x86)/gs/gs9.09/bin/gswin32c.exe" \
-q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT \
-dMaxBitmap=500000000 -dAlignToPixels=1 -dGridFitTT=2 \
"-sDEVICE=pngalpha" -dTextAlphaBits=4 \
-dGraphicsAlphaBits=4 "-r96" -dFirstPage=1 -dLastPage=1 \
-sOutputFile="output.png" "input.pdf"
(which I actually pretty much copied from the command ImageMagick calls when converting a PDF file, but that's another story). I tried changing any of the relevant options (dAlignToPixels=0, dGridFitTT=0/1/2, dTextAlphaBits=2/4 [or without this parameter altogether]) and I even tried to render the PDF to 4 times the resolution and then downscale it, without any noticeable improvement.
Yet, I'm sure there must be some way of decently rendering the PDF with Ghostscript (since TexWorks does), although I'm unable to find it.
Any hint? The PDF is this one.
You could try to render your PDF at a higher resolution. 96dpi just isn't enough for text with 11 pt size.
If you use 192dpi and then scale the display of the resulting image to 50% (wherever you use the PNG), these parts should still appear in the same size as befor, but with a higher resolution. What used to be a 4x7 pixels 's' should now be a 8x14 pixels 's'...
Update
Ok, since my explanation seems to have been not comprehendible enough for the OP, here's the deal.
Generate a PDF file containing the word "Test", using Ghostscript. In my case, it is Ghostscript v9.10:
gs \
-o test.pdf \
-sDEVICE=pdfwrite \
-g230x100 \
-c "/Helvetica findfont \
11 scalefont \
setfont \
1 1 moveto \
(Test) show \
showpage"
From this PDF, generate 6 different images depicting the word "Test", using 6 different resolutions. The gs is still Ghostscript v9.10 (to be checked with gs -version):
for i in 1 2 3 4 5 6; do \
gs \
-o t$(( ${i} * 96 )).png \
-r$(( ${i} * 96 )) \
-sDEVICE=pngalpha \
-dAlignToPixels=1 \
-dGridFitTT=2 \
-dTextAlphaBits=4 \
-dGraphicsAlphaBits=4 \
t.pdf ; \
done
This will create the following PNGs, as confirmed by ImageMagick's identify command:
identify -format "%f : %Wx%H pixels -- %b filesize\n" t[1-9]*.png
t96.png : 31x13 pixels -- 475B filesize
t192.png : 61x27 pixels -- 774B filesize
t288.png : 92x40 pixels -- 1.1KB filesize
t384.png : 123x53 pixels -- 1.43KB filesize
t480.png : 153x67 pixels -- 1.76KB filesize
t576.png : 184x80 pixels -- 2.01KB filesize
Create a sample LaTeX document and embed the different images side by side and/or line by line. Here is my sample code:
\begin{document}
Test
\includegraphics[height=7.5pt]{t96.png}
\includegraphics[height=7.5pt]{t96.png}
\includegraphics[height=7.5pt]{t192.png}
\includegraphics[height=7.5pt]{t288.png}
\includegraphics[height=7.5pt]{t384.png}
\includegraphics[height=7.5pt]{t480.png}
\includegraphics[height=7.5pt]{t576.png}
Test\\
{}
Test <== real text
\includegraphics[height=7.5pt]{t96.png} <-- 96 dpi figure
\includegraphics[height=7.5pt]{t192.png} <-- 192 dpi figure
\includegraphics[height=7.5pt]{t288.png} <-- 288 dpi figure
\includegraphics[height=7.5pt]{t384.png} <-- 384 dpi figure
\includegraphics[height=7.5pt]{t480.png} <-- 480 dpi figure
\includegraphics[height=7.5pt]{t576.png} <-- 576 dpi figure
Test <== real text
\end{document}
Here is a screenshot (at 400% zoom) from the PDF created via LuaLaTeX from the above LaTeX code:
The line with the 8 "Test" words has actual text only in the first and the last word. The 6 words in between are images with 96, 96, 192, 288, 384, 480 and 576 dpi.
I hope you can see now clearly how scaling up your image generation to a higher resolution will result in better quality for your final PDF if you include the higher resolution images into your LaTeX code...
You are rendering text at 11 points, at 96 dpi, that works out to about 14 pixels in height which, frankly, is not a lot (and in my output the 's' is 7 pixels high by 4 wide). Looking at your output all 3 look 'blurry' and the Photoshop output looks overly bold in the capital T.
If you don't want it blurred, then don't set TextAlphaBits, or don't set it to such a high value.
I'd also suggest using the current release (9.15).
I created color separations using
gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r600x600 -sOutputFile=p%08d.tif input.pdf
The outputs are all greyscale separations as documented.
Questions
1. How do I combine just the CYAN and MAGENTA separations (or any combination of colors) to make a PDF file?
2. How do I make sure the output PDF from the combo is in color and not greyscale?
Thanks.
You should be able to use Imagemagick's convert to combine CMYK separations; references:
http://www.productionmonkeys.net/guides/ghostscript/examples
CMYK colors inverted with draw or annotate - ImageMagick forum
Combine 4 grayscale images into a final CMYK image - ImageMagick
Example: first, create RGB pdf with Latex (from https://softwarerecs.stackexchange.com/questions/19210/linux-gui-for-quick-browsing-of-cmyk-separations-of-multi-page-pdf); use this as test.tex:
\documentclass{standalone}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\draw[fill=none,draw=black,line width=2pt] (0cm,0cm) rectangle (4cm,5cm);
\draw[fill=red] (1cm,1cm) circle (1cm) ;
\draw[fill=blue] (2cm,2.5cm) circle (1cm) ;
\draw[fill=green] (3cm,4cm) circle (1cm) ;
\end{tikzpicture}
\end{document}
... then build the PDF with:
pdflatex test.tex
Split RGB pdf into CMYK separations as tiff images using Ghostscript (see original softwarerecs thread for images), which will be called:
gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r150x150 -sOutputFile=test%04d.tif test.pdf
Merge/combine CMYK separations into a CMYK color tiff using Imagemagick:
convert \
test0001\(Cyan\).tif \
test0001\(Magenta\).tif \
test0001\(Yellow\).tif \
test0001\(Black\).tif \
-set colorspace CMYK -negate -combine combined.tif
... and here is how the final combined.tif looks like (I had to do convert combined.tif combined.png to upload it here, else .tif alone is not accepted):
For comparison, here is a png derived from the original PDF (convert -density 150 -flatten test.pdf test.png):
Notice how the colors are slightly different, which is expected due to the colorspace roundtrip. Also, note that for more correct colors, you'll probably have to use ICC profiles during conversion...
Finally, you should find a way to convert/import the final CMYK color TIFF into a PDF... (probably either ghostscript or imagemagick could do that, but I haven't tried it..)
For just cyan and magenta - use a white image with the same size as the channel TIF separations, to insert it in place of the missing separations:
convert -size 240x299 xc:white white.png
... and then do the merge again:
convert \
test0001\(Cyan\).tif \
test0001\(Magenta\).tif \
white.png \
white.png \
-set colorspace CMYK -negate -combine combinedCM.tif
Here is the output (after convert combinedCM.tif combinedCM.png):
Open the separations in an image editor which supports CMYK channels (eg Photoshop), combine the channels as required, save as PDF (or PostScript and use GS to convert to PDF).
This is related to:
Converting PDF to CMYK (with identify recognizing CMYK).
Script (or some other means) to convert RGB to CMYK in PDF?
... 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!
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:
PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? - comp.lang.postscript | Google Groups
... 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!
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.
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.