Created attachment 6899 [details] PostScript Example Document For Testing Raster Drivers Converting a PostScript document containing embedded images using any of the raster devices (e.g. PGM, TIFF, etc) will render the embedded images all black. The command line used is the following: gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pgm -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r600x600 -sOutputFile=file.pgm file.ps With the PGM raster device, for example, any specified resolution above 326 (i.e. -r326x326) will cause the embedded image to be rendered all black. This effect also occurs with the TIFF raster devices but at a different resolution cut-off (I haven't found the exact cut-off value). However, the TIFF fax formats (i.e.. tiffg3, tiffg32d, tiffg4) do not show this problem. Attached is an example PostScript document (pstest.ps), created with OpenOffice, containing an embedded PGM image. This document can be viewed without problem using either gv or gsview. But converting to a PGM raster will completely blacken the embedded image at resolutions above 326. I believe this problem began with gs-9.00.
Marcos, can we have a search svn revs to isolate this?
Created attachment 7016 [details] screenshot.png I can't reproduce this. I tried both 32 and 64 bit of Ghostscript 9.0 and head (r11938) with this command line: bin/gs-dSAFER -dBATCH -dNOPAUSE -sDEVICE=pgm \ -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r600x600 \ -sOutputFile=file.pgm pstest.ps All produced an image identical the attached screenshot. Can you give me more information on your Linux system and Ghostscript? Some things that might be helpful: which release of Linux, 32 or 64 bit OS, where did you get Ghostscript executable from, if you built it yourself which compiler did you use, is the use of -dTextAlphaBits=4 -dGraphicsAlphaBits=4 necessary to reproduce the problem?
(In reply to comment #2) On my system, the problem exists either with or without the options "-dTextAlphaBits=4 -dGraphicsAlphaBits=4." My system is Gentoo Linux 64-bit. Ghostscript is compiled from source using a Gentoo ebuild, which may include some Fedora packages. But I think that it would be best to wait for some verification from other users of ghostscript before proceeding.
A hint for rebuilding -- disable ALL use of shared libraries. Insure that all of the following are specified in you Makefile: SHARE_FT=0 SHARE_LCMS=0 SHARE_LIBPNG=0 SHARE_LIBTIFF=0 SHARE_JBIG2=0 SHARE_JPEG=0 SHARE_JPX=0 SHARE_ZLIB=0 Third party packages may introduce problems. Artifex does thorough testing with the sources we distribute.
The problem has been solved. Certain compiler optimizations, namely the latest Graphite and LTO available with GCC-4.5.1, were somehow responsible. On my Gentoo system, my CFLAGS variable included the following flags: -flto -floop-interchange -floop-strip-mine -floop-block These flags enable the Graphite and LTO optimizations and ghostscript compiled with these flags exhibits the reported problem. Using a different set of flags, CFLAGS=-O2 -march=native, ghostscript was recompiled and the problem disappeared. Ghostscript functions normally now. But the solution raises a different issue. Why are these compiler flags able to degrade the performance of the resulting ghostscript executable? Is the fault entirely with GCC or is the ghostscript code somehow partly to blame? Anyway, for anyone interested in reproducing the original problem, compiling ghostscript with the above-indicated CFLAGS should do the job.