Bug 689734

Summary:	ghostscript 8.62 fails with rangecheck on PDF files with x11alpha device
Product:	Ghostscript	Reporter:	Tor Andersson <tor.andersson>
Component:	Other Driver	Assignee:	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