Bug 51982

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.