From the following CUPS bug report
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"
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.
--- 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 ),
/* 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