Bug 688815 - clist bug with PDF Transparency
Summary: clist bug with PDF Transparency
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: 8.53
Hardware: All All
: P2 normal
Assignee: Ray Johnston
URL:
Keywords: discuss
Depends on:
Blocks:
 
Reported: 2006-07-28 12:33 UTC by Ralph Giles
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer: 190
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Giles 2006-07-28 12:33:40 UTC
Customer reports:

While experimenting with BufferSpace, I've found something else. GS 8.53        
fails to rip the attached file at 2800 dpi and higher, with a bufferspace      
of 2 Mb:                                                                        
                                                                                
gs -DBufferSpace=2000000 -sDEVICE=tiff32nc -sOutputFile=a.tif -r28000           
-dNOPAUSE -f trans.pdf -c quit                                                  
Error: /rangecheck in --.fillpage--                                             
etc...                                                                         
                                                                                
I've tracked the problem a little bit, and found the cause of the problem:     
clist_init_states() returns gs_error_range_check because the "data_size" is
too small. As a result, the device has "permanent_error" set to -15 and        
clist_fill_rectangle immediately fails.                                        
                                                                                
I don't understand exactly what happens. clist_init_states() is called 2        
times with this file (I suppose it's because of the transparency), and the     
second times the number of bands is much higher than the first time. Thus      
the data_size is too small.                                                     
                                                                                
I see in gdev_prn_setup_as_command_list that the BufferSpace value is used      
as base value to compute the data_size. Thus with a higher BufferSpace          
(e.g. 5 Mb) you need to augment the resolution to reproduce the problem.        
                                                                               
Currently we never use less than 10 Mb with our devices. I've computed          
that, roughly, we need 2m x 2m at 1500 dpi to cause the problem. Not very       
common, but possible in a near future. Some printers (5m width)       
will soon reach 800 dpi, so we are not so far.
Comment 1 Ralph Giles 2006-07-28 12:35:28 UTC
Created attachment 2387 [details]
trans.pdf
Comment 2 Ray Johnston 2006-07-28 13:12:03 UTC
Since I have the other BufferSpace bug, I'll take this one too.
Comment 3 Ray Johnston 2007-04-07 16:07:13 UTC
Customer bugs should be P2.
Comment 4 Ray Johnston 2008-05-15 12:40:10 UTC
The tiff32nc device can only support up to 2Gb raster images (since it is
uncompressed). For this file 'trans.pdf' (a 'letter' size page) the maximum
resolution that will fit is -r2310 or thereabouts.

Note that the current ghostscript fails with:
    Error: /rangecheck in --showpage--
when the page is too large for uncomressed tiff.

Otherwise, the issues with transparency and large pages have all been fixed.