\setbeamercolor{normal text} changes text color within included PDF image!

[Ryo Furue]

Hi all,

Is this a bug?

\pdfminorversion=7

\documentclass{beamer}

\setbeamercolor{normal text}{fg=white}%<<<comment out this line

\begin{document}

\begin{frame}

\includegraphics[height=0.5\textwidth]{test}% a PDF image.

\end{frame}

\end{document}

I've found that the setbeamercolor command changes the color of some text in the included PDF image, which I'm attaching to this message.  If you comment out the setbeamercolor command, the text in question is printed in its original color.

The PDF file was edited with Adobe Acrobat Pro (I think it's version IX or was it XI ?) and in PDF version 1.6.

I use texlive 2015.  ("This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) (preloaded format=pdflatex 2015.12.21)") Bemear comes with it.  Mac OS 10.11.4 .

Regards,

Ryo

[Alexander Grahn]

On Fri, May 20, 2016 at 04:16:23AM -0700, Ryo Furue wrote:
>Is this a bug?
>
>\pdfminorversion=7
>\documentclass{beamer}
>\setbeamercolor{normal text}{fg=white}%<<<comment out this line
>\begin{document}
>\begin{frame}
>\includegraphics[height=0.5\textwidth]{test}% a PDF image.
>\end{frame}
>\end{document}
>
>
>I've found that the setbeamercolor command changes the color of some text
>in the included PDF image, which I'm attaching to this message. If you
>comment out the setbeamercolor command, the text in question is printed in
>its original color.
>
>The PDF file was edited with Adobe Acrobat Pro (I think it's version IX or
>was it XI ?) and in PDF version 1.6.

No. This is a bug in the included image test.pdf. It does not set the
colour for stroking and nonstroking operations at the beginning of its
contents and inherits these attributes from the preceeding content.

There are two ways to cope with this situation:

1.) the workaround:

{\color{black}\includegraphics[height=0.5\textwidth]{test}}

2.) repair test.pdf:

Add `q 0 g 0 G' at the start of the content
stream of test.pdf and `Q' at its end. This sets stroking and non-stroking colours
to black. The graphics-state operators `q' and `Q' encapsulate this
setting which prevents the colour from leaking into the content that follows test.pdf.

This (2.) can be done on the uncompressed test.pdf (using e. g. pdftk)
within a text editor.

Attached: test2.pdf (repaired)

[Ryo Furue]

Dear Alexander,

On Friday, May 20, 2016 at 10:16:41 PM UTC+9, Alexander Grahn wrote:

No. This is a bug in the included image test.pdf. It does not set the
colour for stroking and nonstroking operations at the beginning of its
contents and inherits these attributes from the preceeding content.

Ah, thank you!!

Then, that is a bug on the part of Adobe Acrobat Pro.  I used Acrobat to edit the PDF image.  The original image didn't have this problem: When included in LaTeX, all text is printed in black.  I then deleted some objects from it and moved the text in question to its present location within Acrobat Pro, and then the edited version shows this problem.  That suggests that Acrobat Pro forgot to retain the color specification when it deleted the objects or to include the color specification when it moved the text.

Also thank you for the instruction to edit PDF.  I didn't know that PDF is editable like PostScript.

Regards,

Ryo

[Ryo Furue]

On Saturday, May 21, 2016 at 2:36:25 AM UTC+9, Ryo Furue wrote:

Dear Alexander,

On Friday, May 20, 2016 at 10:16:41 PM UTC+9, Alexander Grahn wrote:

No. This is a bug in the included image test.pdf. It does not set the
colour for stroking and nonstroking operations at the beginning of its
contents and inherits these attributes from the preceeding content.

Oh, and that makes me wonder whether the default behavior of includegraphics be changed.

When you display my "broken" PDF image using a regular PDF viewer such as Preview, Acrobat Reader, and Skim, you find all text displayed in black.  It's impossible to tell that some of the text is "colorless" unless you suspect that.

Shouldn't includegraphics mimic the behavior of those viewers (by default), then?  Shouldn't includegraphics insulate the embedded PDF from color specifications of the surrounding?

I can see that "color leakage" can be useful in some situations, as when you want to create "reverse video" slides: You first create "colorless" PDF images and control their colors from within LaTeX.  But, I guess such behavior would better be optional.

Regards,

Ryo