I have a file that noone pdfeditor (evince nor kpdf) can read... only ghostview... so I want to "rewrite" that file in a good form $ gs -dBATCH -dNOPAUSE -dQUIET -sDEVICE=pdfwrite -sOutputFile=FATTURA.bis.pdf FATTURA.pdf using gs version 8.62 creates this output *** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** Warning: stream operator not terminated by valid EOL. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> GLS-Italy <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. and then it creates a new well formatted pdf file, visibile on every editor ---------------------------------------------------------------- but... using the last version, 8.70 **** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. Segmentation fault and no file will be created so, imho, the first behavior is better. thanks and bye
I agree the previous behaviour was better; please attach a copy of FATTURA.pdf and we'll see what we can do.
Created attachment 5648 [details] FATTURA.pdf
search-svn-revs shows that this broke in r8962: r8962 | ken | 2008-08-11 07:16:18 -0700 (Mon, 11 Aug 2008) | 10 lines Move the interpretation of PostScript (and PDF) color spaces from PostScript into C.
Although it was my (large) change for PS colour that exposed this problem, I'm not sure its actually my fault. The last call into the colour code is considerably before the actual point of error, which occurs trying to 'exec' a chunk of unavailable memory. Also there are no colour spaces in the file likely to cause a problem (simple device spaces throughout). I think the problem is more to do with trying to fix a broken PDF file which just happened to work before, and just happens not to work after (notice the numerous 'stream operator not terminated by valid EOL' messages) I'm trying to narrow the problem down to see where it actually lies, this will probably take some time.
Created attachment 5649 [details] ps_log.zip OK, I don't think this is me, I think its something to do with the PDF interpreter, but I don't know what. The PostScript interpreter seems to be reading lines from a file (the input file possibly) and executing them, in a loop I think. I'm going to CC Alex in to solicit his opinion, I've attached the log of PostScript operations executed in case that's helpful. The crash occurs after the final exec.
CC'ing Alex. Alex please have a look at this problem and tell me what you think is wrong.
There's something wrong with scanning of big names. I'm taking over.
Increase the size of the initial buffer in the scanner dynamic area to accept the string of maximum valid size. Protect the buffer from overflow when the scanner state is saved during reading of a name that exceed max name length. The following patch has been committed as a rev. 10312. http://ghostscript.com/pipermail/gs-cvs/2009-November/010038.html Regression testing shows no differences.