11

There are some questions regarding rendering problems (color shifts) in Adobe Acrobat Reader when using transparency in tikz and friends or transparent PNGs.

The solutions (that work for me so far) look similar to

\pdfpageattr{/Group <</S /Transparency /I true /CS /DeviceRGB>>}

I have followed this for a couple of years (since I also had the same problem).

Here's a list of some of the resources I colleced and used in the past years:

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.

[Taken from PDF colour model and LaTeX (bold formatting by me)]

The question is: is it possible to address this problem so that the "normal" user does not have to cope with this individually?

Update 1

Due to a request from Ulrike Fischer (in the chat), I added an example code: Apparently, it also depends on the viewer. In addition, I do not know why the line width of the first box is also different in one viewer. Can you verify this on your systems?

\documentclass{standalone}
\usepackage{tikz}

% \pdfpageattr{/Group <</S /Transparency /I true /CS /DeviceRGB>>}

\begin{document}

\begin{tikzpicture}
\node[
    draw = black, 
    line width = 2pt, 
    fill = blue, 
    text = white,
    fill opacity = 0.8, % <-- Problematic code
    ] 
        {Text};
\end{tikzpicture}

\begin{tikzpicture}
\node[
    draw = black, 
    line width = 2pt, 
    fill = blue, 
    text = white,
%   fill opacity = 0.8,
    ] 
        {Text};
\end{tikzpicture}

\end{document}

Adobe Acrobat X Pro enter image description here

Adobe Acrobat Reader DC enter image description here

Adobe Acrobat X Pro (with \pdfpageattr{/Group <</S /Transparency /I true /CS /DeviceRGB>>}) enter image description here

Update 2

It seems that with the current (March 2018) Adobe Reader (Adobe Acrobat Reader DC) the problem is solved. I would like to keep the question (closed is ok) for further reference.

Update 3

By accident, I noticed today (2018-05-19) that the current pgfplots manual look different (color-wise) in Chrome and in Adobe Acrobat X Pro. I assume that this is also caused by the same issue.

enter image description here

Improve this question
26
  • 2
    In addition, since Adobe Reader is the reference viewe for the pdf format, I think it is still worth talking about it – Dr. Manuel Kuehner Feb 27 '18 at 0:50
  • 3
    @HenriMenke With all due respect, I am really happy to see both the question and the constructive parts of your comments, which allow a poor marmot like myself to see all issues collected at one place and also see your links pointing to those good souls doing all the updating and maintaining. – user121799 Feb 27 '18 at 1:37
  • 3
    @marmot But this isn't the place. It needs to be reported upstream. Complaining here about the non-fulfilment of a feature request or non-fixing of a bug which has not even been reported is not only pointless, but rather mean. I mean, if you were maintaining this software, how would you feel about a public post like this on an unrelated site, apparently trying to show how long you've let things fester for, by somebody who didn't even bother to tell you about the problem? Frankly, I would be somewhat pissed off. Developers provide avenues for such reports: common courtesy means using them. – cfr Feb 27 '18 at 1:41
  • 7
    I'm voting to close this question as off-topic because bugs and feature requests should be reported upstream. If workarounds are required meanwhile, questions asking for those are entirely reasonable, as are questions aimed at determining whether something is a bug or asking for help pinpointing the problem. But general gripes about the non-responsiveness of developers to bugs/requests which haven't even been made are off-topic here and rude besides. – cfr Feb 27 '18 at 1:46
  • 4
    see also github.com/latex3/graphics-def/issues/16 – David Carlisle Feb 27 '18 at 7:38