Cfrgtkky

_{(Strictly speaking, this is a question about XeLaTeX and the xcolor package but I’m assuming that the issue is actually with the color model of PDF.)}

I’m having the problem that colours in my PDF don’t match. For example, I screen grabbed a colour value as RGB, declared it in my document and the resulting colour was completely different. To illustrate:

Both colours were grabbed off the screen – on the left, from the PDF generated by XeLaTeX. On the right, the original colour whose RGB value I tried using in LaTeX (in case my issue isn’t clear: the colours on top are differnt, yet they have the same HSB values).

So I thought that perhaps RGB doesn’t map without loss to whatever colour model PDF used and tried the obvious alternative – CMYK, which, after all, is often used in print (right?). Again, the colours are off, but now less perceptibly.

Another example (this time using CMYK values):

The colour is supposed to have the CMYK value (0.94, 0.63, 0.04, 0.07). I have declared the colour in my code as follows:

definecolor{primary}{cmyk}{0.94,0.63,0.04,0.07}

The bottom half of the picture is created by TikZ. The top half is actually an EPS that I included via includegraphics. The EPS was created in Inkscape. Neither of the above colours has the correct CMYK value when examined with a colour picker:

The top is (0.96, 0.67, 0.08, 0.19). The bottom is (0.92, 0.61, 0.06, 0.09).

(Incidentally, when I try to enter the “correct” CMYK value in Inkscape, it “auto-corrects” my value to some other value. Wut?)

Now, this mightn’t seem like a TeX related question at all. But, long story short,

How can I reliably reproduce colours in pdfLaTeX/XeLaTeX?

_{I know that the issue is confounded by the fact that PNG (which is the format of the above screenshots) uses an own colour model and so the screen shots may look different on your PC than on mine. But since I pasted the colours into the same image, I think that the difference should be preserved.}

The colour model of PDF is extremely sophisticated and bewilderingly flexible. You can read all about it in section 8.6 of the pdf specification (you can download it here). There are a number of prepress tools that exist for managing a colourspace workflow with PDF. Adobe Acrobat Professional has an "output preview" tool which is what I use.

PDF supports many colour spaces: gray, cmyk, rgb, indexed, LAB, deviceN. This allows for things like spot colours (and tints thereof), special metallic or varnish inks, 6-colour printing, duotone, multitone, registration colours, and so on. You can have multiple such colour spaces within the same PDF (although for printing you'll need to convert to some common space, at least for each page). There can even be multiple variants of the same colour space family (for example sRGB and the variant of RGB that your scanner or digicam uses; cmyk with different dot gains, etc).

The situation gets even more complicated when you involve transparency (see section 11.7 of the spec): in order to overlay one object on another the PDF viewer needs to convert them to a common "blending" colour space, which can be specified in various ways in the PDF (including at the "page group" level: this explains why including transparency on a page can change the appearance of other objects on that page, because those objects now have to run through a colour space conversion). There are various restrictions and special cases, for example device colours cannot be converted reliably into CIE based spaces (such as sRGB). Since transparency groups can nest, there can be multiple rounds of colour space conversion during rendering.

TeX support

Now for latex support via xcolor: If you load xcolor with the (default) natural option there will be no colour space conversions, and you will have access to the PDF "DeviceRGB", "DeviceCMYK" and "DeviceGray" spaces. Eg, textcolor[rgb]{1,0,0}{DeviceRGB red}, and textcolor[cmyk]{0,1,1,0}{DeviceCMYK Red}. Your PDF viewer (for screen) or your printer driver (for hardcopy) will have to convert colour spaces if necessary. If you load xcolor with options like rgb or cmyk then xcolor will convert to that colour space, using the formulas from section 6.3 of the xcolor manual (which are not very sophisticated -- compare them to the formulas in 10.3 of the PDF spec, with BG(k) and UCR(k) functions, etc).

If you use the dvips route to producing PDF then you may be able to access also spot colours and other colour spaces, using the named and ps models. I believe Context makes these things somewhat easier, but I don't speak from experience.

Remember that converting device colour spaces to the screen colour space is in general not well defined, and different viewers may do it slightly differently, resulting in the mismatches you've observed.

One good solution with pdflatex is to use only deviceRGB (for screen) or deviceCMYK (for most printers) and then set an "Output Intent" to define the device space as, eg, sRGB IEC61966-2.1. See section 14.11.5 of the PDF spec. The pdfx package does this, for example (although that package is pretty rough around the edges and you'll generally need to edit it directly to get it to work). A more "proper" way to use calibrated colour spaces would be the "Default Color Spaces" mechanism (section 8.6.5.6) which specifies a way to remap DeviceRGB, DeviceCMYK, DeviceGray into device-independent CIE-based colour spaces. I'm not aware of any latex package that makes use of this PDF1.1 feature, though. (Grepping through the sources suggests that again Context may have some support for this).

The case of the different coloured swatches

In your first pair of images, note that the left image has a gray triangle in the upper right corner. This indicates that it is a deviceRGB colour from a screen grab. Click on the icon to the left of the "HSB Sliders" indicator and choose the colour space as for the right swatch, and you'll see that the colours will then match.

The case of inkscape "autocorrecting" CMYK

Perhaps this article will be helpful.

Expanding on the following remark of Lev Bishop:

Remember that converting device colour spaces to the screen colour
space is in general not well defined, and different viewers may do it
slightly differently, resulting in the mismatches you've observed.

I noticed pdf viewer Evince does not render colors as specified. E.g., take the following document with grayscale boxes:

documentclass[10pt]{article}



usepackage[pdftex,rgb]{xcolor}

definecolor{gray0}{gray}{0}

definecolor{gray2}{gray}{0.2}

definecolor{gray5}{gray}{0.5}

definecolor{gray8}{gray}{0.8}

definecolor{gray10}{gray}{1}



begin{document}

%Draw grayscale boxes

frame{color{gray0}rule{2cm}{2cm}}

frame{color{gray2}rule{2cm}{2cm}}

frame{color{gray5}rule{2cm}{2cm}}

frame{color{gray8}rule{2cm}{2cm}}

frame{color{gray10}rule{2cm}{2cm}}

end{document}

Open the pdf with Evince and pick with Gpick yields:

0.09 (indeed, black text is not rendered as true black as in rgb(0, 0, 0))

0.27

0.54

0.81

0.99

Make a screenshot of the pdf, open with Gnome's Image Viewer:
The picked colors match the colors specified in Latex document.

Open the pdf with Adobe Reader and pick with Photoshop (on Windows) yields:
The picked colors match the colors specified in Latex document.

Open in Evince a pdf-document generated with LibreOffice and pick the text:
0.09 (again, black text is not rendered as true black as in rgb(0, 0, 0))

Conclusion: Evince or its pdf backend Poppler does not render colors as specified.

Rendering inconsistencies, unfortunately, seem to be part of all pdf viewers:
https://srg.doc.ic.ac.uk/projects/pdf-errors/results.html
https://link.springer.com/article/10.1007/s10664-018-9600-2

For the interested, details about how Evince renders colors:

Plot specified gray vs picked gray (using wolframalpha.com):

Plot[{0, 0.09}, {0.2,0.27}, {0.5,0.54}, {0.8,0.81}, {1,0.99}]


Fit a curve through the dataset:

Fit[{0, 0.09}, {0.2,0.27}, {0.5,0.54}, {0.8,0.81}, {1,0.99}]

A linear approximation comes very close: grayEvince = 0.9*graySpecified + 0.09

Conclusion: Evince (or Poppler) particularly renders dark colors too light. It maps the range [darkest,lightest] to [0.09,0.99] instead of [0,1]

Final request:
Can somebody pick the color black with Gpick in another Poppler-based pdf viewer? This way we can determine whether the rendering problem lies with Evince or Poppler.