Created attachment 18348 [details] Pdf issuing warning when converted to JPEG by imagemagick When a PDF file is not completely compliant and "-sOutputFile=-" is used, warnings are included in the standard output, corrupting the output file. These warnings should instead be redirected to the standard error. For instance the attached file has this text warnings (2 times) at the top of the JPEG file, corrupting the entire file: **** Error: stream operator isn't terminated by valid EOL. Output may be incorrect. To reproduce it: 1. Use Git version b4521b8 (Tue Oct 22 10:57:59 2019 +0100) (can be reproduced with 9.26-9.50) and compile it 2. Launch the command line `gs -sDEVICE=jpeg -sOutputFile=- -dFirstPage=1 -dLastPage=1 -dSAFER -r150 -dBATCH -dNOPAUSE -q PdfCausingImagemagickError.pdf >output.jpg 2>errors.err` 3. The file errors.err is empty and there are two warnings at the top of output.jpg, as shown by `head -n 4 output.jpg` **** Error: stream operator isn't terminated by valid EOL. Output may be incorrect. **** Error: stream operator isn't terminated by valid EOL. Output may be incorrect.
(In reply to Seb35 from comment #0) > When a PDF file is not completely compliant and "-sOutputFile=-" is used, > warnings are included in the standard output, corrupting the output file. > These warnings should instead be redirected to the standard error. Warnings are not errors, so no. The PDF interpreter (being written in PostScript) has always worked in this fashion. I'd recommend that you don't pipe the output to stdout, many devices won't work properly if you do that anyway.
Well, in the meantime (thanks for the quick answer), I just found myself how to do it by adding the parameter -sstdout=%stderr, redirecting the actual image to stdout and errors to stderr. Sorry for the noise. For reference, the original bug was on MediaWiki https://phabricator.wikimedia.org/T50007, I will propose such commit there.
(In reply to Seb35 from comment #2) > Well, in the meantime (thanks for the quick answer), I just found myself how > to do it by adding the parameter -sstdout=%stderr, redirecting the actual > image to stdout and errors to stderr. I haven't tried it, but you will probably want to set -sOutputFile *before* you do that. Ghostscript processes command line options sequentially, if you redirect stdout to stderr before you set the output file to stdout, you may find that it ends up also being redirected to stderr. Or it may not, like I say I have not checked and its possible that '-' ignores any such redirection. I'd need to plough through the code to find out > Sorry for the noise. Not a problem, and thanks for posting the follow up. > For reference, the original bug was on MediaWiki > https://phabricator.wikimedia.org/T50007, I will propose such commit there. That would be good, thanks.
I just tried both ways '-sstdout=%stderr' before and after '-sOutputFile=-' and it works equally with my example. But I will follow your advice, there could be more strange files out there.