8 Replies Latest reply: Oct 17, 2010 8:06 AM by bersbers

# Different font rendering depending on image transparency

Hi,

this is a cross-post from the Adobe Reader forum, where no one was able to help me. It is about PDF rendering issues in Acrobat Reader, concerning pdf files created with latex. I would be glad if you could help me out; I hope the "PDF language" forum is the right place to ask.

bersbers wrote:

Hi,

please take a look at this file:

http://www.jtartlabs.com/test/test.pdf (this is not my server and not my files, but they illustrate my problem)

The two pages in this file render differently on my system, as can be seen here:

Reader 9.3.4, Windows 7 x64, also on Windows XP SP3 32 bit

The file was created using tex and this minimal example:

\documentclass{book}
\usepackage{graphicx,lipsum}

\begin{document}
\lipsum[1]
Surrounding text is NORMAL
\includegraphics{singleclickbutton2}
\lipsum[5]
\newpage
\lipsum[1]
Surround text is BOLD
\includegraphics{singleclickbutton3}
\lipsum[5]
\end{document}


You see that there should be no difference in the pages except for two different image files, but obviously there is. This effect goes away as soon as I disable the "Smooth text" option, but this is ugly and I cannot expect my readers to do so.

It SEEMS that part of the problem is that singleclickbutton3 has some transparency information, while singleclickbutton2 does not. (All the files are available at http://www.jtartlabs.com/test/).

What causes this issue? More important, what can I do to prevent it - either in tex or using a postprocessor?

Thanks,

bers

• ###### 1. Re: Different font rendering depending on image transparency

It's an aspect of the implementation of the PDF standard in Acrobat concerning the choice of default "transparency blending space" when a producer doesn't include an explicit one in the PDF.

The way to correct it is for the PDF producer to ensure that when all content on the page is in RGB, that an RGB-based blending space be specified in the page's transparency group.

I believe that the current version of PdfTeX do the right thing - but this file was produced with an older version.

• ###### 2. Re: Different font rendering depending on image transparency

Thank you very much for your answer. I recreated the pdf file using the current (until 6 weeks ago) version 1.40.10, and it has the same problem. I also tried the current 1.40.11 via MikTex 2.9 beta - same result. I re-opened a related pdfTex bug report, let's see what comes out of it.

http://sarovar.org/tracker/?group_id=106&atid=493&func=detail&aid=896

• ###### 3. Re: Different font rendering depending on image transparency

So I found a two commands which should fix this issue by doing what you suggest, add RGB information. The first is this one, which I found here:

http://sarovar.org/tracker/?group_id=106&atid=493&func=detail&aid=741

\pdfpageattr{/Group <<

/CS /DeviceRGB

/Type /Group

/S /Transparency

>>}

It gets correctly added to the pdf, but it does not chance the output rendering.

D:\Desktop\test>fc original.pdf new.pdf

Comparing files original.pdf and TEST.PDF

***** original.pdf

/MediaBox [0 0 612 792]

/Parent 6 0 R

***** TEST.PDF

/MediaBox [0 0 612 792]

/Group << /CS /DeviceRGB /Type /Group /S /Transparency >>

/Parent 6 0 R

*****

***** original.pdf

/MediaBox [0 0 612 792]

/Parent 6 0 R

***** TEST.PDF

/MediaBox [0 0 612 792]

/Group << /CS /DeviceRGB /Type /Group /S /Transparency >>

/Parent 6 0 R

*****

.

.

.

Neither does the one which adds this:

D:\Desktop\test>fc original.pdf new.pdf

Comparing files original.pdf and NEW.PDF

***** original.pdf

/MediaBox [0 0 612 792]

/Parent 6 0 R

***** NEW.PDF

/MediaBox [0 0 612 792]

/Group << /S /Transparency /I true /CS /DeviceRGB>>

/Parent 6 0 R

*****

***** original.pdf

/MediaBox [0 0 612 792]

/Parent 6 0 R

***** NEW.PDF

/MediaBox [0 0 612 792]

/Group << /S /Transparency /I true /CS /DeviceRGB>>

/Parent 6 0 R

*****

So I suppose there is something else interfering. I checked for all ColorSpace arguments in both files and found that there was already a DeviceRGB ColorSpace-argument in the original file:

D:\Desktop\test>egrep -a "ColorSpace|CS" original.pdf

/ColorSpace /DeviceRGB

/ColorSpace /DeviceRGB

/ColorSpace /DeviceGray

<</Type/Group /S/Transparency /CS/DeviceRGB /I true>>

D:\Desktop\test>egrep -a "ColorSpace|CS" new.pdf

/Group << /S /Transparency /I true /CS /DeviceRGB>>

/ColorSpace /DeviceRGB

/Group << /S /Transparency /I true /CS /DeviceRGB>>

/ColorSpace /DeviceRGB

/ColorSpace /DeviceGray

<</Type/Group /S/Transparency /CS/DeviceRGB /I true>>

Do you have any other ideas why AR is ignoring the ColorSpace arguments?

Here is one more thing, showing that indeed the "DeviceGray" thing really seems to have an influence:

Thanks,

bersbers

• ###### 4. Re: Different font rendering depending on image transparency

And another piece of the puzzle: This issue is not visible for the first file open in Acrobat:

- Have Acrobat Reader closed.

- Start test.pdf - issue not visible.

- Close test.pdf, NOT the reader.

- Open test.pdf - issue visible.

• ###### 5. Re: Different font rendering depending on image transparency

Hey everybody,

i have the same problem and an update to a new version of Miktex has not solved the problem. Since nobody posts something to the thread any longer, I am wondering if that problem is fixed, and i miss the fix, or if the solution is posted somewhere else?

Could anybody give me a hint how to circumvent that problem?

Kind regards,

Ede

• ###### 6. Re: Different font rendering depending on image transparency

Hi,

as lrosenth pointed out, the newest versions of pdfTex (miktex 2.8/2.9) already do the right thing by adding blending space information to the page group. The pdf files I describe are created using one of these versions, but AR seems to ignore these settings. So, definitely not fixed yet.

• ###### 7. Re: Different font rendering depending on image transparency

Can someone post an updated sample and I'll investigate?

• ###### 8. Re: Different font rendering depending on image transparency

Yes, here it is. It's two files, test1.pdf and test2.pdf created using the newest MikTex 2.9, updated all packages right now.

test1.pdf is

\documentclass{book}

\usepackage{graphicx,lipsum}

\begin{document}

\lipsum[1]

Surrounding text is NORMAL

\includegraphics{singleclickbutton2}

\lipsum[5]

\end{document}

with singleclickbutton2.png being a 24 bit png image file. Get the png files here:

http://www.jtartlabs.com/test/

test1.pdf does not contain an entry about the blending space, so the default RGB space is used.

test2.pdf is the exact same code with singleclickbutton3.png, a 32 bit png image (24 bit + alpha channel). test2.pdf does contain this:

C:\Users\xxx\Desktop\Test>more test2.pdf | grep CS

<</Type/Group /S/Transparency /CS/DeviceRGB /I true>>

However, the rendering still seems to take place in CMYK space, resulting a bolder, blacker font. This effect is observed especially if you open the file in AR, close the file (but not AR!), and open the file again. Then look at the two files at 6.25% zoom level and note the difference.

Get the pdf files here: