For some reason including a working colorplot image into a new document via \includegraphics seems to modify the image. Is there any workaround to this problem?

My MWE looks harmless:




Colormap.pdf is created by the code from this question and looks in the correct version very colourful:

enter image description here

but in the the example document the output is as follows:

enter image description here

As this problem is most likely related to the included pdf file here is a link: colormap.pdf. The resulting broken document is linked here: include_colormap.pdf

Update: ImageMagick complains when I want to use the resulting pdf document further:

Error reading a content stream. The page may be incomplete.
Warning: Form stream has unbalanced q/Q operators (too many q's)
File did not complete the page properly and may be damaged.

This file had errors that were repaired or ignored.
The file was produced by:
>>>> LuaTeX-0.76.0 <<<<
Please notify the author of the software that produced this
file that it does not conform to Adobe's published PDF

This all happens on Windows using the current LuaTeX from MiKTex 2.9 (Version beta-0.76.0-2013062419 (rev 4627))

  • colourmap.pdf and the PDF from your MWE which uses colourmap.pdf look identical here (as they should). – AlexG Jul 5 '13 at 12:03
  • which tex system are you using? – David Carlisle Jul 5 '13 at 12:20
  • @DavidCarlisle: I use LuaTeX in the most recent version from MiKTeX 2.9. – Alexander Jul 5 '13 at 12:22
  • 1
    I used pdflatex which produced the expected result. lualatex lead to the (bad) result you reported. TeXLive-2013 here. – AlexG Jul 5 '13 at 12:33
  • @AlexG: Thanks for trying to reproduce the issue. So it is in some way connected to lualatex. – Alexander Jul 5 '13 at 12:39

Since the included graphics file colormap.pdf is correct, this here is a bug in lualatex.

I could track it down: apparently, lualatex messes around with the decode parameter of the shading.

If you take a text editor, open the include_colormap.pdf and make a text substitution below

27 0 obj

by replacing

/Decode[--2147.16352 16384 --2147.16352 16384 0 1]


/Decode[-16383.99992 16384 -16383.99992 16384 0 1]

the resulting graphics is entirely correct: it can be viewed and imagemagick does not complain any longer.

This is a bug in lualatex; I do not know why it modified the /Decode field in this context.

The solution above would be a valid workaround; these shadings always have the same decode array. In other words: you can write some script which applies the search-and-replace until lualatex has been fixed. If you apply the replacement only in the context of /ShadingType 6 you will be on the safe side: I do not think that many programs generate such shadings.

Side-note: if you apply search-and-replace in pdf files, you have to keep the number of bytes intact.

  • Perhaps you can try to write \pdfcompresslevel=0 as first line into the file - perhaps thats causing the trouble (just guessing). – Christian Feuersänger Jul 6 '13 at 18:31
  • Thanks a lot for this investigation Christian! I can confirm that after replacing the offending line the image is restored. I will try with a search and replace script until the lualatex team fixes this bug (pdfcompresslevel unfortunately did not change the wrong decode parameter). – Alexander Jul 6 '13 at 19:31
  • Ok. Perhaps it is some mistake in the numeric range clipping: -16383.99992 is almost the smallest allowed number, and -2147 are the first digits of the smallest integer. Perhaps some unit conversion mismatch caused the problem. – Christian Feuersänger Jul 6 '13 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.