Bug 51982 - pdftops fails for 600+ dpi
Summary: pdftops fails for 600+ dpi
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: utils (show other bugs)
Version: unspecified
Hardware: All Solaris
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-11 13:27 UTC by Torsten Kasch
Modified: 2012-07-20 22:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
PostScript Output (300dpi) (1.45 MB, application/postscript)
2012-07-11 13:29 UTC, Torsten Kasch
Details
PostScript Output (600dpi, broken) (702.62 KB, application/postscript)
2012-07-11 13:30 UTC, Torsten Kasch
Details
default-testpage.pdf (38.92 KB, application/pdf)
2012-07-11 20:22 UTC, Torsten Kasch
Details
My "official" patch for the 600 dpi problem (1.11 KB, patch)
2012-07-17 08:42 UTC, Thomas Freitag
Details | Splinter Review

Description Torsten Kasch 2012-07-11 13:27:56 UTC
pdftops seems to produce broken PostScript for me when requesting a rasterization resolution of 600 dpi or more. Lower values (I've tried with 300 and 150) seem to be fine.

I've used the "default-testpage.pdf" file from cups-filters-1.0.18 and produced the output as follows:

pdftops -r 300 default-testpage.pdf test-300.ps  # output ok
pdftops -r 600 default-testpage.pdf test-600.ps  # output broken

This is poppler-0.20.1 compiled on Solaris 10/x86 with the Oracle Solaris Studio 12.2 compiler; the effect is the same on Solaris 10/Sparc.
Comment 1 Torsten Kasch 2012-07-11 13:29:31 UTC
Created attachment 64107 [details]
PostScript Output (300dpi)
Comment 2 Torsten Kasch 2012-07-11 13:30:20 UTC
Created attachment 64108 [details]
PostScript Output (600dpi, broken)
Comment 3 Albert Astals Cid 2012-07-11 18:45:37 UTC
Can you please attach the pdf or give us a link to it?
Comment 4 Torsten Kasch 2012-07-11 20:22:31 UTC
Created attachment 64124 [details]
default-testpage.pdf

This is the "default-testpage" document which is part of the cups-filters package that can be found at http://www.openprinting.org/download/cups-filters/cups-filters-1.0.18.tar.gz. It serves as a template when generating a test page print job in CUPS.
Comment 5 Thomas Freitag 2012-07-12 10:29:18 UTC
Seems to be the new functionality of rendering a page in stripes, introduced by merging with xpdf 3.0.3. 300 dpi is rendered in one stripe, 600 dpi takes two. If I reduce the stripes to one also for 600 dpi (s. line 3130 in PSOutputDev.cc) it works fine. But the reason why striping doesn't work is not obviously for me, perhaps we encountered once again a merging mistake be me...
Comment 6 Torsten Kasch 2012-07-12 11:51:03 UTC
Indeed, setting "nStripes = 1" results in a PostScript file four times the size of the 300dpi variant (which is what I'd expect when doubling the resolution of a bitmap, not halving its size as before) -- and its content does look much better now. :-)
Comment 7 Thomas Freitag 2012-07-14 07:45:08 UTC
I found now the time to have a deeper look into it: it was not really the striping itself but our optimization of output:
If it is a color output but we detect that the color image has only gray components, we reduce the output to a grayscale image. Unfortunately this overwrites the numComps of the splash bitmap, so the next stripe will always be seen as a grayscale image, so the initialization of that image output will be a grayscale image but the data will remain color pixels.
This is quite easy to repair:
Introduce an additional local variable initialNumComps:

int numComps, initialNumComps;

instead of just

int numComps;

Initialize the new variable before starting the loop:

  // render the stripes
  initialNumComps = numComps;
  for (stripeY = sliceY; stripeY < sliceH; stripeY += stripeH) {

and reset numComps for each stripe:

    // draw the rasterized image
    bitmap = splashOut->getBitmap();
    numComps = initialNumComps;

Unfortunately I'm not able to create a patch for it in the moment, because my code base still waits that the patch uploaded yesterday for bug 51822 to be committed.
But I'll create a patch if necessary after the patch for bug 51822 will be committed.
Comment 8 Torsten Kasch 2012-07-16 06:34:38 UTC
It looks like I was able to get this done myself with your instructions. :-) Thank you very much!
Comment 9 Albert Astals Cid 2012-07-16 22:26:21 UTC
patch for 51822 commited
Comment 10 Thomas Freitag 2012-07-17 08:42:11 UTC
Created attachment 64302 [details] [review]
My "official" patch for the 600 dpi problem

(In reply to comment #9)
> patch for 51822 commited
And here the patch for this bug (tested also with 1200 dpi)
Comment 11 Albert Astals Cid 2012-07-20 22:03:15 UTC
Fix 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.