Bug 689734

Summary: ghostscript 8.62 fails with rangecheck on PDF files with x11alpha device
Product: Ghostscript Reporter: Tor Andersson <tor.andersson>
Component: Other DriverAssignee: Hin-Tak Leung <htl10>
Status: RESOLVED FIXED    
Severity: normal CC: christinedelight.top85, michael.vrhel
Priority: P4    
Version: 0.00   
Hardware: Macintosh   
OS: MacOS X   
Customer: Word Size: ---
Attachments: onepage.pdf

Description Tor Andersson 2008-03-05 05:58:06 UTC
Compiled and installed out of the box on Mac OS X 10.5, ghostscript
fails with an error on many PDF files.

From the ghostscript-8.62.tar.bz2 I did "sh autogen.sh; make; sudo make install".
This is the error message:

GPL Ghostscript 8.62 (2008-02-29)
Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Error: /rangecheck in --run--
Operand stack:
   --nostringval--   --dict:9/18(L)--   102.14   57.86
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   -
-nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1905   1   3   
%oparray_pop   1904   1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--   --
nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   
false   1   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1145/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --dict:75/200(L)--   --
dict:108/127(ro)(G)--   --dict:275/300(ro)(G)--   --dict:22/25(L)--   --dict:4/6(L)--   --
dict:27/40(L)--
Current allocation mode is local
GPL Ghostscript 8.62: Unrecoverable error, exit code 1
Comment 1 Tor Andersson 2008-03-05 05:59:46 UTC
Created attachment 3836 [details]
onepage.pdf

Simple one page PDF file that exhibits the bug.
Comment 2 Ralph Giles 2008-03-05 11:13:50 UTC
I can reproduce with MacOS 10.4 (intel) and 64 bit linux.
Comment 3 Ralph Giles 2008-03-05 12:01:48 UTC
This issues is transparency related. It only occurs with the x11alpha device,
and adding -dNOTRANSPARENCY avoids the blank page. Tor, can you confirm whether
it renders correctly with other devices or -dNOTRANSPARENCY, or are there
elements missing?

Assigning to myself as an x11alpha bug.

Ray traced the rangecheck to zdiscardtransparencygroup (ztrans.c:236)
Comment 4 Ray Johnston 2008-03-05 14:19:36 UTC
This dies due to an 'unknowerror' return from 'gx_no_get_bits' when trying to
do a 'copy_alpha'. The current device is the pdf14RGB' device which doesn't
have a 'get_bits' or 'get_bits_rectangle' function.

The problem results when there is a bbox compositor in the chain. The pngalpha
device, doesn't define a 'create_compositor' call, so the 'senpdf14_trans' never
installs the bbox device in the compositor chain.

The 'fill_with_rule' checks the bbox device's color_info.anti_alias and the
value is '4' even though the underlying 'pdf14RGB' device has color_info.anti_alias
set to '1'. Then 'gs_make_mem_abuf_device' is called leading (eventually to the
failure).

When the 'bbox' compositor is not in the chain, the pdf14RGB device's color_info
anti_alias is seen by the 'fill_with_rule', so the 'abuf' device is not used.

Note that this means that ALL transparency files currently 'fall back' to
not using anti-aliased rendering (the effect is visible in the pgnalpha
device and the windows 'display' device).

I'm not yet sure of the 'best' fix. We obviously would like to retain anti-
aliased text for the x11alpha device, but this has to default to AlphaBits=1
when a PDF with transparency is encountered.

Note that the -sDEVICE=x11 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 works this
way (non transparency pages are anti-aliased, pages with transparency are not).
 
Comment 5 Ray Johnston 2008-03-05 14:33:11 UTC
Follow up.

The difference is that the x11alpha device's prototype (which is used by the
bbox_create_compositor) when it calls gx_device_init from gx_device_bbox_init
has the anti_alias bits set to '4' (using the std_device_dci_alpha_type_body
macro).

The x11 device prototype doesn't have these set.

One solution might be to set the anti_alias values _after_ the bbox compositor
is installed in the chain (when the device is the x11alpha device).
Comment 6 Hin-Tak Leung 2010-05-02 03:12:30 UTC
Grabbing a Ralph's bugs.
Comment 7 Hin-Tak Leung 2010-05-10 14:53:16 UTC
still a problem with r11213 .
Comment 8 Michael Vrhel 2011-04-09 05:29:05 UTC
fixed with rev 12380