12

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

  • Viewer issues are off-topic. – Henri Menke Feb 27 '18 at 00:35
  • 1
    @HenriMenke Then all the linked questions are off-topic ;). Please let me ask the question - I really believe that this will improve LaTeX and help less experienced users. I tried it at meta and we agreed to post it here. I would find it very sad if I would have to close it. – Dr. Manuel Kuehner Feb 27 '18 at 00:47
  • 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 00:50
  • 2
    @Dr.ManuelKuehner Asking this “question” is absolutely pointless. Submit this fix to people maintaining the pdftex.def driver and the PGF bugtracker rather than reposting it here to collect internet points. (-1) – Henri Menke Feb 27 '18 at 00:53
  • 2
    I will not fight in the comments about this. Read the comments in meta and maybe you can see that I don't do it because of some virtual reputation system ':). My impression is that the pros here are being positive and do not assume the worst. Let's agree to disagree and end the discussion, ok? – Dr. Manuel Kuehner Feb 27 '18 at 00:58
  • 1
    You could post your comment as an answer and I promise that I will upvote despite your -1. – Dr. Manuel Kuehner Feb 27 '18 at 01:01
  • Reported to LaTeX: https://github.com/latex3/graphics-def/issues/16 I don't have a SourceForge account so I cannot report to PGF. Just delete this question, it serves no purpose. – Henri Menke Feb 27 '18 at 01:03
  • 2
    I don't really see what an answer could look like here. The question isn't a technical one: it is about the intentions of a particular individual or individuals. And the closest technical question is one you already know the answer to i.e. a workaround. So I find it hard to see how this is not off-topic. That is not to say that the feature request isn't important: but this is not the relevant bug tracker, so not the place for feature requests. If you had linked existing reports to the relevant bug trackers, it would be off-topic, but more understandable. Why didn't you report it? – cfr Feb 27 '18 at 01:37
  • 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. –  Feb 27 '18 at 01: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 01: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 01:46
  • 2
    Note that the discussion in comments on the Meta question did not support asking this question here. Rather, it was suggested that asking where to report the problem might be on-topic. That would fall under the help with pinpointing I mentioned above. But that's not what you've asked here at all. That's why it is clearly off-topic. – cfr Feb 27 '18 at 01:51
  • 1
    @cfr I see your point, and definitely these things should have been posted first to those good souls who do all this if it is obvious how these can be contacted. Please don't get me wrong, I have never made an effort finding out who these people are, and never bothered thanking them which I definitely should have done. Nevertheless, at least for me this post has drawn some of my attention to these issues. –  Feb 27 '18 at 01:56
  • 4
    see also https://github.com/latex3/graphics-def/issues/16 – David Carlisle Feb 27 '18 at 07:38
  • 1
    @Dr.ManuelKuehner I think a question of “why does it not work” (asking for an explanation) may be appropriate, or “how can I get it to work” (asking for tricks/workarounds) or even “what sort of changes to the LaTeX internals would it take for this to get fixed”. But the question of whether an unspecified group of people intend to fix it or not is not really useful for this site; for all you know, even if they do intend to fix it, the problem may turn out to be harder than expected and the fix may never reach you—so what will you do with an answer of “yes” right now? – ShreevatsaR Mar 07 '18 at 21:11
  • @ShreevatsaR Let's discuss this when we are both in the chat. I see your point. – Dr. Manuel Kuehner Mar 07 '18 at 21:18
  • 2
    @Dr.ManuelKuehner I took the liberty of rewriting the actual question from “Do the LaTeX architects here plan to address this problem…” to “is it possible to address this problem…”, because I think it's actually a great question for the site if not asked in the original form. :-) Feel free to revert if you really intended to ask the original question. – ShreevatsaR Mar 07 '18 at 21:38
  • @ShreevatsaR Thank you very much. I appreciate the edit. Would you mind keeping the link to the original question on meta? – Dr. Manuel Kuehner Mar 07 '18 at 21:53
  • 2
    I think this kind of information is important to TeX users, particularly those who circulate something such as a CV prepared with TeX. –  Mar 11 '18 at 21:26
  • 1
    The issue seems to be resolved in AR-DC. The document built from the first code box (no \pdfpageattr) looks the same in AR-DC and Evince. – AlexG Mar 12 '18 at 09:46
  • @AlexG Thanks. Other topic: Do you also get the strange line width effect as shown in my screen shots? – Dr. Manuel Kuehner Mar 12 '18 at 12:29
  • @Dr.Manuel No, the full linewidth (2pt) extending to the pageborder is shown in DC. (AR-DC==Evince). – AlexG Mar 12 '18 at 12:34
  • @Dr.ManuelKuehner By the way, your AR-DC rendering doesn't show the line-width issue either. It is exactly the same rendering as in Evince. Thus, this (longstanding) problem seems to be fixed, finally. What do you think is still wrong? – AlexG Mar 12 '18 at 12:51
  • @AlexG You are right. It replied during work on my phone and didn't double check before I sent the message. – Dr. Manuel Kuehner Mar 12 '18 at 19:32
  • I think PDF.js should be left out of this discussion because that viewer is usually following actual viewers from quite some distance behind. Personally I've switched to SumatraPDF both for SyncTeX issues and also for speed. Its performance is quite satisfying, corner cases notwithstanding. – percusse May 19 '18 at 12:19
  • @percusse Thanks for the tip (although in this case, the Chrome viewer looks right :)). – Dr. Manuel Kuehner May 19 '18 at 12:20
  • That \pdfpageattr doesn’t suppress the extra page group extra object copied from the embedded PDFs though… uaaaaah! – mirabilos Nov 19 '21 at 22:43

0 Answers0