[texhax] Abode Reader Error 131, and color shifts with transparency

[Brian Dunn]

> On Thu, 20 Oct 2016 21:08:43 +0200
> Martin Schröder <martin at oneiros.de> wrote:
> 
> > Fix your images.  

Some followup:

I found and installed an older version of Adobe Reader for Linux
(v9.5.5) in order to quickly test image and compilation variations and
their interoperability with (one old version of) Adobe Reader.

In testing I came up with a simple document containing just two images
on a gray background, and no text. The first image is a PNG with a few
colors and some transparency, created by GIMP.  The second image is a
vector drawing of a box created by Inkscape.  (Both a fairly recent
version.)

Using pdflatex I was able to get Reader to give an error with this
simple document.  If the image order was reversed, or if a another copy
of either image was added, then Reader was happy.

If the document was compiled with lualatex or xelatex then Reader was
happy.

If the PNG image with colored blocks was cropped a bit, Reader still
complained.  If the image was cropped more, then Reader became happy.

If the PNG was run through optipng, which chose to reduce the color bit
depth, then Reader was happy.

If the PNG was run through the ImageMagick convert program with no
options, it also reduced the bit depth, and then Reader again was happy.

Comparing the GIMP-produce PNG with the ImageMagick-produced PNG using
the ImageMagick identify program, the following are the
relevant differences seen by the identify program:

---

1c1
< Image: colors.png
---
> Image: colors_convert.png
63c63
<   Gamma: 0.454545
---
>   Gamma: 0.45455
69c69
<   Background color: white
---
>   Background color: srgba(255,255,255,1)
85,88c85,90
<     png:IHDR.bit-depth-orig: 8
<     png:IHDR.bit_depth: 8
<     png:IHDR.color-type-orig: 6
<     png:IHDR.color_type: 6 (RGBA)
---
>     png:cHRM: chunk was found (see Chromaticity, above)
>     png:gAMA: gamma=0.45454544 (See Gamma, above)
>     png:IHDR.bit-depth-orig: 2
>     png:IHDR.bit_depth: 2
>     png:IHDR.color-type-orig: 3
>     png:IHDR.color_type: 3 (Indexed)
91a94
>     png:PLTE.number_colors: 4
92a96,98
>     png:text: 2 tEXt/zTXt/iTXt chunks were found
>     png:tIME: 2016-11-10T02:02:06Z
>     png:tRNS: chunk was found
95c101
<     filename: colors.png
---
>     filename: colors_convert.png
98c104
<   Filesize: 3.07KB
---
>   Filesize: 727B

---

The most interesting lines comparing the original 8-bit image with the
optipng-generated image are:

85,88c85,88
<     png:IHDR.bit-depth-orig: 8
<     png:IHDR.bit_depth: 8
<     png:IHDR.color-type-orig: 6
<     png:IHDR.color_type: 6 (RGBA)
---
>     png:IHDR.bit-depth-orig: 2
>     png:IHDR.bit_depth: 2
>     png:IHDR.color-type-orig: 3
>     png:IHDR.color_type: 3 (Indexed)
91a92
>     png:PLTE.number_colors: 3
92a94
>     png:tRNS: chunk was found

---

The above information may be sufficient for someone to figure out
what is happening.  If interested, I can place online copies of the
images and the .tex file for further testing.

---

Also, there is a color shift associated with transparency and RGB/CMYK
PDF documents generated by TeX.  The methods mentioned online for
fixing this color shift for lualatex are slightly out of date now with
lualatex having made some recent changes.  The following seems to work
with pdflatex, recent lualatex, and xelatex:

% to fix colors while transparency is in use:
\usepackage{iftex}
\ifXeTeX
\usepackage{eso-pic}
\AddToShipoutPicture{%
\makeatletter%
\special{%
pdf: put @thispage <</Group << /S /Transparency /I
true /CS /DeviceRGB>> >>}% <-- remove line wrap from previous line
\makeatother%
}
\else
\ifLuaTeX
\edef\pdfpageattr {\pdfvariable pageattr}% for new versions
pdfpageattr {/Group << /S /Transparency /I true /CS /DeviceRGB>>}
\else% pdflatex
\pdfpageattr {/Group << /S /Transparency /I true /CS /DeviceRGB>>}
\fi
\fi

---


Brian


-- 
Brian Dunn
BD Tech Concepts LLC
http://www.BDTechConcepts.com
bd at BDTechConcepts.com

http://www.linkedin.com/in/bdtechconcepts/