Starting with ce35f1657aac012a492f05f61b56a605243fe83e the following command line produces output which is missing much of the content of earlier versions: bin/gs -r72 -o test.ppm -sDEVICE=ppmraw ./Bug689006.pdf This is also affect file Bug690179.pdf. There is a new warning produced during the conversion under Mac OS X: GPL Ghostscript GIT PRERELEASE 9.05 (2011-03-30) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 2. Page 1 Substituting font Helvetica-Bold for TCSMONO. Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 3426056 2102277 6249960 4958419 3 done. **** Error reading a content stream. The page may be incomplete. **** File did not complete the page properly and may be damaged. Page 2 Substituting font Helvetica-Bold for TCSMONO. **** This file had errors that were repaired or ignored. **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification.
Analysis shows that the issue does not occur with -O0 or -O1. Further analysis shows that generating zfapi.o with -O2 appears to necessary to cause the problem.
I take it this isn't reproducible using gcc?
I can't reproduce this on my Mac - Snow Leopard XCode 3.2.3, gcc 4.2.1. I did: CC="gcc -m64" ./configure make And ran gs as you have above. I don't get an error, nor warnings. Any other info that might help?
My iMac is running Lion and the latest compiler: uname -a: Darwin imac 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64 gcc --version: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
(In reply to comment #2) > I take it this isn't reproducible using gcc? No, but it is reproducible on Linux with clang: ./autogen.sh CC=clang ; make marcos@amd64:[62]% bin/gs -r72 -o test.ppm -sDEVICE=ppmraw ~/artifex/tests_private/comparefiles/Bug689006.pdf GPL Ghostscript GIT PRERELEASE 9.05 (2011-03-30) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 2. Page 1 Substituting font Helvetica-Bold for TCSMONO. Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 3433144 2055086 6249960 4960366 3 done. **** Error reading a content stream. The page may be incomplete. **** File did not complete the page properly and may be damaged. Page 2 Substituting font Helvetica-Bold for TCSMONO. **** This file had errors that were repaired or ignored. **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. marcos@amd64:[63]%
Created attachment 8300 [details] First guess patch..... I'm fairly sure this is a compiler bug. First, these files don't have a font CDevProc in it, so the commit listed doesn't change the behavior in zfapi.c at all. Secondly, removing a variable assignment for a variable which, due to the lack of a CDevProc, is not used anyway, causes the problem to go away. The actual problem seems to be that we get a spurious call to the fapi_finish_render() function, which *seems* to stem from the main interpreter loop. But, because there is no CDevProc, we never push that function onto the exec stack with these files (I was able to add debug code that proved that was true). So far, the best solution I've come up with is the attached patch. There is a tiny (likely unmeasurable) performance implication of this change, hence I've made it only happen when compiling with clang. I'll look at bit more next week, though - can't face reading compiler assembly at the weekend!
(In reply to comment #6) > I'll look at bit more next week, though - can't face reading compiler assembly > at the weekend! I haven't followed this properly, but indeed llvm (AFAIK clang also uses that as the backend) seems the common denominator. If I were to look at this - which I do not intend to, thank you very much! - knowing the problem is narrowed down to one file being compiled at -O2 or -01/-00, I would agree that keeping the two versions of the one object file under the two conditions, and comparing the compiler assembly would be the definitive approach... Good luck, and hope your head does not hurt too much afterwards :-).
This no longer happens with the current master. Presumably fixed as a side effect.