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
Created attachment 3836 [details] onepage.pdf Simple one page PDF file that exhibits the bug.
I can reproduce with MacOS 10.4 (intel) and 64 bit linux.
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)
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).
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).
Grabbing a Ralph's bugs.
still a problem with r11213 .
fixed with rev 12380