From the following CUPS bug report http://www.cups.org/str.php?L2210 I got a test PDF file with some text and a transparent rectangle over the text. CUPS prints it as a black rectangle (bug in XPDF-based pdftops filter). XPDF (newest version) and acroread show it correctly, and Ghostscript (current trunk on SVN) shows a completely white page (saves toner, but also not correct). I hope this was not already reported, but otherwise this is a simple test file for the regression tests.
Created attachment 3170 [details] Transparent rectangle over black text. The text should be readable.
This is likely to be memory usage issue. On my (rather old) Windows box "pdf2ps foo.pdf foo.pd" fails with: pdf2ps foo.pdf foo.ps [a+]gs_malloc(large object chunk)(200463400) = 0x0: failed Error: /rangecheck in --run-- The default resolution for pdf2ps is 720 dpi. Everything works OK at 600 dpi on all recent versions starting from 8.15.
Alex's comment seems to be irrelevant. Ghostcript can display this file fine to x11 (even with -dTextAlphaBits=4 -dGraphicsAlphaBits=4) but the x11alpha device shows a white page. Probably this is a bug in x11alpha. I'll look into this and see if I can isolate the problem.
I get the problem also with "-sDEVICE=x11 -dMaxBitmap=10000000".
> I get the problem also with "-sDEVICE=x11 -dMaxBitmap=10000000". Argh, I wish I read your comment before debugging ;-(. Below is a workaround for x11alpha (if MaxBitmap is not set). It is also an indication of where the problem is: gdevxini.c:x_set_buffer probably messes up the device initialization when maxbitmap is set. As usual we should see if we even need to be supporting this business before fixing it. Index: gdevx.c =================================================================== --- gdevx.c (revision 8608) +++ gdevx.c (working copy) @@ -231,7 +231,7 @@ FAKE_RES * DEFAULT_HEIGHT_10THS / 10, /* x and y extent (nominal) */ FAKE_RES, FAKE_RES, /* x and y density (nominal) */ 3, 24, 255, 255, 256, 256, 4, 4 ), - 50000000) + 0) /* If XPutImage doesn't work, do it ourselves. */ static int alt_put_image(gx_device * dev, Display * dpy, Drawable win,
Created attachment 3903 [details] don't use bbox create compositor Another (untested) solution, don't use the bbox create compositor routine (see the patch). More importantly what this bug shows is the pdf 14 device does not support antialiased graphics at all. If MaxBitmap is greater than zero an error is produced, if it is 0 the graphics are not anti-aliased. By inspection gdevp14.c:pdf14_determine_default_blend_cs() returns PDF14_DeviceRGB for additive color spaces, consequently the anti-alias setting of the device are never seen. I guess the color info antialias setting would be taken into account if the determined blend color space was PDF14_DeviceCustom, this is the only blend space that would receive the antialias setting from the target device. I did not test anti-aliasing under these circumstances, but I suspect it would fail.
Confirmed with 8.70rc1. Passing to Michael.
Either of the two suggestions (-dMaxBitmap=<smallvalue> with either -sDEVICE=x11/x11alpha, or remove the bbox_create_compositor() line) works to make the graphics and text appear; setting MaxBitmap to a low/zero value is probably more desirable for image quality but suffers for speed, while removing bbox_create_compositor the other way round, I think. while looking at how the pdf is processed I found that the last screen update is quite a lot earlier than the compositor is invoked; and it appears that the off-screen buffer is drawn correctly (at least with some black pixels); so my guess is that in the case of off-screen composition, areas of the screens aren't marked for needing updating and therefore not copied from the buffer to screen, so the screen is left blank.
Question: is this also related to bug #690559? This because my workaround attached to this bug also change the behaviour of the bounding box for overprints and seems to work at least with the attached pdf.
fixed in rev 12380