Change color in finished pdf file

Question

Suppose I have a finished PDF file, say a figure generated from some software, where the ink is black. I would include it in a document. Suppose I want to include it in a beamer presentation with black background.

Is there a way to configure the include so i can specify whatever is black should be displayed white? If not, what command line tools could I use to process the PDF file?

Answer 1

Easy case with uncolored PDF and pdfTeX (unhappily very seldom):

The PDF file contains some drawings without explicit color settings and the image will be included by the pdftex driver of the graphics package.

The following file generates such an image:

\documentclass{article}
\usepackage[active,tightpage,floats]{preview}
\begin{document}
\begin{figure}
\Huge\bfseries\sffamily
\setlength{\fboxrule}{2pt}
\fbox{Hello World}
\end{figure}
\end{document}

The following file includes the image (t.pdf) and changes its colors.

\documentclass{article}
\usepackage{color}
\usepackage{graphicx}
\pagecolor{black}
\color{white}
\begin{document}
\Huge\bfseries
\noindent
Some text.\\
\includegraphics{t.pdf}\\
Some text.\\
\textcolor{yellow}{\includegraphics{t.pdf}}\\
Some text.
\end{document}

This trick does not work with other drivers, because the other drivers normalize the color before the image is included. If pdftex.def is given the option resetcolor then the color is set to \normalcolor during image inclusion.

Manual color fixes

With some knowledge of the internals structures the PDF file can be fixed manually. First the compressed page contents needs to be uncompresed, e.g.:

pdftk test.pdf cat output test-uncompress.pdf uncompress

Then the pages content streams need to be identified and the color operations can be either changed or deleted (by overwriting with spaces). Best is not to change the size of the object otherwise the file offsets of the objects in the xref table needs to be updated. BTW, also PDF (or PS) use % as comment char. Then the file can be recompressed.

Or the PDF file is converted to PostScript (e.g. with pstopdf from xpdf). Editing is easier if changing the file size does not matter. PostScript does not have a xref table. However, the detection of the color operators can be more difficult, because often they are renamed or hidden in procedures. Unlike PDF, PostScript is a programming language.

Programs for processing vector images like Inkscape

If the PDF file can be successfully imported in Inkscape or similar programs, the colors could be changed there.

Bitmap conversion

As last resort the image can be converted to a bitmap image (ghostscript and other convertes). That means quality loss because of pixel data. But many image processing programs should be able to change the colors.

Generating inverse colors can even be done by a feature of the PDF format that is supported by pdftex.def. Colors can be inverted via the /Decode array (except images with indexed color spaces). Each color component has then two float values inbetween 0 and 1. Thus the number of color components must be known (Mono: 1, RGB: 3, CMYK: 4)

\includegraphics[decodearray=1 0 1 0 1 0]{rgbimage.png}

For example, the ghostscript device png16m can be used to generate PNGs for this usage. More details are explained in the PDF reference. The options of pdftex.def are shortly explained in the file itself.

Answer 2

Yesterday, I have been fighting a similar problem: while xelatex of TeXLive2018 was producing PDF files without hard-stored blacks, it turned out that TeXLive2021 produces files with immutable blacks. (This may be due to xdvipdfmx's version change 20180217 → 20210318. This broke my usage scenario of my “Emoji-includer”.)

The difference is due to the following change in the generated PDF file (with added spaces):

- q 1 0 0 1 72 -62.967 cm 0 G 0 g 0 g 0 G BT /F1 9.9626 Tf -72 64.65 Td[<1841>]TJ ET Q
+ q 1 0 0 1 72 -62.967 cm                 BT /F1 9.9626 Tf -72 64.65 Td[<1841>]TJ ET Q

inside a stream in a PDF object which is the content of every PDF object of /Type /Page (the page above contains only a glyph indexed by [<1841>]).

My work-around

After uncompression, run

perl -wpe "BEGIN{binmode STDIN; binmode STDOUT} s/(?<!\S)(0\s+[gG])(?!\S)/q( ) x length $1/ge" emoji-from-list-uncompress.pdf >emoji-from-list-nocolor.pdf

This follows — in general — the Heiko’s answer on this page and sebschub’s comment on this answer. However, we edit away g and G commands instead of rg, RG, k and K from this comment.

The editing command above may have a chance to be not specific enough. In the file I can see, the g/G⸣s come in long groups. So the command

    perl -wpe "BEGIN{binmode STDIN; binmode STDOUT} s/(?<!\S)((0\s+[gG]\s*?){2,})(?!\S)/q( ) x length $1/ge" emoji-from-list-uncompress.pdf >emoji-from-list-nocolor.pdf

may be much more robust. It looks for at least 2 black-g-or-G commands in a row .(These perl commands are in Windows’ shell syntax. Change "⸣s to '⸣s on Unixy systems.)

Warning: the resulting PDF file is still uncompressed. Without compressing it, including it in other files increases their sizes (unnecessarily). (Use the pdftk command in Heiko’s answer with compress instead of uncompress.)