(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:


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.

  • 2
    I have no clue about this, but it's funny that when I try to read the color from your first image (on OS X with the DigitalColor Meter) even on the “solid” area the values flicker when you move a bit up and down. (Edit: Ah, it's a jpg, that's why) Commented Jan 31, 2011 at 15:48
  • 1
    did you \usepackage[dvipdfx,cmyk]{xcolor} ?
    – user2478
    Commented Jan 31, 2011 at 15:59
  • 2
    According to the GIMP, the two colors in your first picture do not have the same HSV values, the first one has hue of 30, the second mostly 35 (with few spots of 34). I believe that in general, conversion between different color spaces is device dependent, so if you use different device profiles, you can get different results. Commented Jan 31, 2011 at 16:16
  • 1
    @Konrad: \usepackage[xetex,...]{xcolor} is also supported by xcolor
    – user2478
    Commented Jan 31, 2011 at 16:26
  • 4
    This question opens up a huge can of worms. Colour spaces are immensely complicated beasts: Even RGB and RGB be different things! There is sRGB, which is the standard colour profile for computer monitors, and there is Adobe RGB, which allows for a bigger gamut of colours (especially, more greens) and is more suited for photos. It is my understanding that one should avoid CMYK altogether unless the goal is to produce PDF for a specific printing press and paper whose characteristics are known. Commented Jan 31, 2011 at 16:35

2 Answers 2


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 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.

  • 22
    This answer is awesome on so many levels. It gives a concise explanantion of (1) PDF colour models, (2) TeX support for colour models, (3) OS X colour support and the correct usage of the “Colors” dialog, which has somehow eluded me for years, and finally (4) a pointer to the bewildering behaviour of Inkscape. What can I say? Thanks a lot Commented Jan 31, 2011 at 20:46
  • 6
    @Alan: I will, but first I will wait two days and make this question a bounty. Then I can award more points for the answer. Commented Feb 1, 2011 at 7:50
  • 2
    Do I understand it right, that for example \usepackage[cmyk]{xcolor} will convert all color definitions in the document that use another color model? sth like \definecolor{halfblack}{gray}{0.5} would in the end be CMYK?
    – Gambhiro
    Commented May 6, 2011 at 7:41
  • 1
    By '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.' do you mean that it's not generally a good idea to use the same PDF file for the screen and the print version of a document?
    – Christian
    Commented Feb 24, 2013 at 22:51
  • 2
    @Christian: yes, having separate screen and print versions gives the most control over colour, although such a level of control is rarely needed for most simple documents, in which case I would choose CMYK or RGB depending on the primary medium of the document. You only want complete control if you're at the level of worrying about rich blacks, trapping, and such things. (There may be other reasons, unrelated to colour, to have separate print and screen versions, such as doing away with recto/verso distinction for screen, adding a thumb index for print).
    – Lev Bishop
    Commented Feb 25, 2013 at 5:47

2020-05-21 update: My remarks about Evince rendering pdf's too bright are not true. See the comments section for details.

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:



%Draw grayscale boxes

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))

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:

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}]
Inconsistent colors Evince
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.

  • Not sure whether I correctly perform the experiment, but even with Evince on current Debian unstable, the black from the document given here appears as #000000. Same thing with xpdf, which uses libpoppler (package libpoppler82 version 0.71.0-6 on my system).
    – frougon
    Commented Apr 17, 2020 at 16:42
  • 1
    I later found out that Evince slightly brightens its appearance when it is not selected. So, the Evince window was slightly brightened every time I sampled it with GPick. So yes, you're right, the colors are okay if you have the Evince windows selected.
    – Bart
    Commented Apr 20, 2020 at 13:13
  • 1
    Ouch, these things are full of traps. :)
    – frougon
    Commented Apr 20, 2020 at 13:14
  • :) Indeed they are
    – Bart
    Commented Apr 23, 2020 at 18:25

You must log in to answer this question.

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