Bug 42064

Summary: Uncorrect rendering with poppler-qt4 when showing pdf's with transparency embedded inside other pdf's
Product: poppler Reporter: Ivo Anjo <knuckles>
Component: splash backendAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: Thomas.Freitag
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: testcase showing the issue
Original file that was embedded using pdflatex
latex testcase
Okular rendering, 1280x1024, broken page (png)
Okular rendering, 1280x1024, ok page (png)
Another testcase with lots of text

Description Ivo Anjo 2011-10-20 08:04:50 UTC
Created attachment 52592 [details]
testcase showing the issue

The attached pdf has incorrect rendering on okular and open-pdf-presenter (which both use poppler-qt4), but no issues with evince nor acroread.

The only difference between the two pages is that a white background was inserted.

pdflatex file used to generate the test case is:
\documentclass{beamer}
\usepackage[english]{babel}

\begin{document}
\setbeamercolor{background canvas}{bg=white}
\frame{Broken Version\\\includegraphics[width=\columnwidth,keepaspectratio]{vbox.pdf}}

\setbeamercolor{background canvas}{bg=}
\frame{OK Version\\\includegraphics[width=\columnwidth,keepaspectratio]{vbox.pdf}}
\end{document}
Comment 1 Ivo Anjo 2011-10-20 08:05:22 UTC
Created attachment 52593 [details]
Original file that was embedded using pdflatex
Comment 2 Ivo Anjo 2011-10-20 08:05:46 UTC
Created attachment 52594 [details]
latex testcase
Comment 3 Albert Astals Cid 2011-10-20 08:18:01 UTC
I see no differences between the "OK" version and the broken version. Can you attach a screenshot of what you get? Which poppler version are you running?
Comment 4 Ivo Anjo 2011-10-20 08:24:31 UTC
I have libpoppler 0.16.4-0ubuntu1.1 (latest version on ubuntu 11.04 repos).

The difference isn't very great, but most lines and text glyphs get a bit thicker from one version to another.

I'll attach two pngs from okular.
Comment 5 Ivo Anjo 2011-10-20 08:25:05 UTC
Created attachment 52595 [details]
Okular rendering, 1280x1024, broken page (png)
Comment 6 Ivo Anjo 2011-10-20 08:25:27 UTC
Created attachment 52596 [details]
Okular rendering, 1280x1024, ok page (png)
Comment 7 Albert Astals Cid 2011-10-20 08:32:59 UTC
Ah, on a closed inspection i see what you mean, I was looking for something bigger when you said "broken".

To be honest this is so minor (imo of course) and we have so many other bigger things that personally I am not going to work on it.
Comment 8 Ivo Anjo 2011-10-20 08:50:22 UTC
Created attachment 52597 [details]
Another testcase with lots of text

I chose that figure because it showed that the issue was with both font rendering, and other lines.

Here's another test case which I think makes it more obvious how worse it gets, especially on a smaller window -- I can read the "OK Version" with okular on "fit width" and smaller than 640x480, where the other version just is plain unreadable.

I hope that with this version I can convince you that the issue is important :)
If not, thanks at least for looking into this and replying fast (if only most other bug reports had this kind of feedback!), and hope it gets fixed soon.
Comment 9 Albert Astals Cid 2011-10-20 09:05:15 UTC
Yeah, I can see in this case text looks a bit unreadable. 

Thomas do you have time to have a look at this?
Comment 10 Thomas Freitag 2011-10-20 10:46:00 UTC
(In reply to comment #9)
> Yeah, I can see in this case text looks a bit unreadable. 
> 
> Thomas do you have time to have a look at this?

The difference seems to be, that with

1 g
1 G
q
0 0 362.835 272.126 re
f
Q

the text looses it transparency. I will have a look at it in more detail, but to be honest, it will take a little while
Comment 11 Thomas Freitag 2011-10-30 09:01:27 UTC
I had now a deeper look into it, and now encountered the following: if the background color is white (and without any transpoareny), the black text color is brightened. This seems to be a bug in calculating the destination color in Splash;;pipeRun in general with white background, but the calculation is so complex, that I can't really understand what is going on there. What I can do and already tried, is to examine the background color, and if it is white, ignore it in the calculation of the destination color. I encountered the problem in CMYK an RGB model, so probably this also happens in other colorspaces.
It is just a hack, and I have to run a complete regression test, bevause this is a real central routine in splash, but I don't know when I have the time to run this test. On the other hand a regression test could lead to another and better solutiion...
What Do You think about it?
Comment 12 Albert Astals Cid 2011-10-30 14:13:05 UTC
If it is not an obvious fix, better wait a bit, we are in process of trying to merge xpdf3.03 changes over to poppler and it has a few splash changes so better do that change after we merge everything over.
Comment 13 Thomas Freitag 2012-05-02 00:42:46 UTC
Seems to be solved after closing merge
Comment 14 Albert Astals Cid 2012-05-10 10:54:06 UTC
Fixed in poppler 0.20

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.