Bug 61413 - PDF renders wrong if window is big enough or full screen presentation
Summary: PDF renders wrong if window is big enough or full screen presentation
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-24 22:48 UTC by Asser Lähdemäki
Modified: 2013-03-01 18:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of the faulty rendering (114.02 KB, text/plain)
2013-02-24 22:48 UTC, Asser Lähdemäki
Details
The PDF file which can be used to reproduce (214.38 KB, application/octet-stream)
2013-02-24 22:49 UTC, Asser Lähdemäki
Details
tiling pattern fix (702 bytes, patch)
2013-02-26 10:02 UTC, Thomas Freitag
Details | Splinter Review
tiling pattern fix (1.65 KB, patch)
2013-03-01 08:51 UTC, Thomas Freitag
Details | Splinter Review

Description Asser Lähdemäki 2013-02-24 22:48:54 UTC
Created attachment 75462 [details]
Screenshot of the faulty rendering

Attached PDF file renders wrong when the window size is grown enough or if shown in presentation mode.

The said PDF is reported to work correctly with poppler 0.18, version I am using is 0.22.1. The file also works correctly in adobe reader and Foxit reader for example.
Comment 1 Asser Lähdemäki 2013-02-24 22:49:53 UTC
Created attachment 75463 [details]
The PDF file which can be used to reproduce
Comment 2 Albert Astals Cid 2013-02-24 22:52:54 UTC
FWIW Fabio says he's git bisecting the error
Comment 3 Fabio D'Urso 2013-02-24 23:28:25 UTC
According to some git bisect tests, it seems that wrong rendering started with
3349a8dd7e0469cc5b5aaa8dd929c6078183ef86
Splash: Avoid bogus memory error for tilingPattern
Comment 4 Thomas Freitag 2013-02-25 09:00:56 UTC
(In reply to comment #3)
> According to some git bisect tests, it seems that wrong rendering started
> with
> 3349a8dd7e0469cc5b5aaa8dd929c6078183ef86
> Splash: Avoid bogus memory error for tilingPattern

Yes, You're true, Fabio: It is this part of SplashOutputDev::tilingPatternFill:

+    if ((unsigned long) result_width * result_height > 0x800000L)
+      return gFalse;

It's quite easy to solve:

    if ((unsigned long) result_width * result_height > 0x10000000L)
      return gFalse;

(which means a new limit of 16384 * 16384 pixel)

BUT: This also means, that Gfx::doTilingPatternFill doesn't wotk correctly with this sample, because returning false means that Gfx should do the work by its own.

@Albert: Should I try to solve the Gfx::doTilingPatternFill bug, or can You live with the new limit?
Comment 5 Thomas Freitag 2013-02-26 10:02:30 UTC
Created attachment 75569 [details] [review]
tiling pattern fix

Damnish! Of course it was once again my mistake: The problem was NOT in Gfx::doTilingPatternFill, but that SplashOutputDev::tilingPatternFill already changed the CTM and didn't restore it on this emergency exit. The attached patch solves it.
Comment 6 Albert Astals Cid 2013-03-01 00:26:52 UTC
Should we do the same in the return gFalse of if (!isfinite(ctm[i])) ?
Comment 7 Thomas Freitag 2013-03-01 08:51:28 UTC
Created attachment 75727 [details] [review]
tiling pattern fix

(In reply to comment #6)
> Should we do the same in the return gFalse of if (!isfinite(ctm[i])) ?

Oh, very attentively. And of course everywhere where it returns gFalse, even if I don't think that Gfx::doTilingPatternFill is then able to draw the tiling pattern correctly. But at least it is cleaner code. The attached patch does it!
Comment 8 Albert Astals Cid 2013-03-01 18:17:17 UTC
Commited


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.