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.
Created attachment 64107 [details] PostScript Output (300dpi)
Created attachment 64108 [details] PostScript Output (600dpi, broken)
Can you please attach the pdf or give us a link to it?
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.
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...
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. :-)
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.
It looks like I was able to get this done myself with your instructions. :-) Thank you very much!
patch for 51822 commited
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)
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.