Bug 42064 - Uncorrect rendering with poppler-qt4 when showing pdf's with transparency embedded inside other pdf's
Summary: Uncorrect rendering with poppler-qt4 when showing pdf's with transparency emb...
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-20 08:04 UTC by Ivo Anjo
Modified: 2012-05-10 10:54 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
testcase showing the issue (27.68 KB, application/pdf)
2011-10-20 08:04 UTC, Ivo Anjo 		Details
Original file that was embedded using pdflatex (8.51 KB, application/pdf)
2011-10-20 08:05 UTC, Ivo Anjo 		Details
latex testcase (340 bytes, text/x-tex)
2011-10-20 08:05 UTC, Ivo Anjo 		Details
Okular rendering, 1280x1024, broken page (png) (30.33 KB, image/png)
2011-10-20 08:25 UTC, Ivo Anjo 		Details
Okular rendering, 1280x1024, ok page (png) (30.41 KB, image/png)
2011-10-20 08:25 UTC, Ivo Anjo 		Details
Another testcase with lots of text (38.99 KB, application/pdf)
2011-10-20 08:50 UTC, Ivo Anjo 		Details
View All

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.