Bug 689340 - Problem displaying PDF to x11alpha
Summary: Problem displaying PDF to x11alpha
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: X Display Driver (show other bugs)
Version: master
Hardware: All All
: P4 normal
Assignee: Michael Vrhel
QA Contact: Bug traffic
URL: http://www.cups.org/str.php?L2210
Keywords: bountiable
Depends on:
Blocks: 690559
  Show dependency treegraph
Reported: 2007-07-06 15:48 UTC by Till Kamppeter
Modified: 2011-04-09 05:00 UTC (History)
2 users (show)

See Also:
Word Size: ---

Transparent rectangle over black text. The text should be readable. (148.06 KB, application/pdf)
2007-07-06 15:50 UTC, Till Kamppeter
don't use bbox create compositor (365 bytes, patch)
2008-03-30 12:06 UTC, Henry Stiles
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2007-07-06 15:48:21 UTC
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.
Comment 1 Till Kamppeter 2007-07-06 15:50:09 UTC
Created attachment 3170 [details]
Transparent rectangle over black text. The text should be readable.
Comment 2 Alex Cherepanov 2007-07-06 17:31:38 UTC
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.
Comment 3 Ray Johnston 2007-07-10 10:40:05 UTC
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. 
Comment 4 Till Kamppeter 2007-07-10 10:55:04 UTC
I get the problem also with "-sDEVICE=x11 -dMaxBitmap=10000000".
Comment 5 Henry Stiles 2008-03-26 09:33:11 UTC
> 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,
Comment 6 Henry Stiles 2008-03-30 12:06:47 UTC
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.
Comment 7 Ralph Giles 2009-07-30 10:37:15 UTC
Confirmed with 8.70rc1. Passing to Michael.
Comment 8 Hin-Tak Leung 2009-12-18 01:30:40 UTC
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.
Comment 9 Dr. Werner Fink 2009-12-18 02:33:55 UTC
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.
Comment 10 Michael Vrhel 2011-04-09 05:00:06 UTC
fixed in rev 12380