I encountered a PDF file that works fine on Adobe Reader but doesn't display in GhostScript. The error message I'm getting is: **** File has an unbalanced >> (close dictionary). **** Incorrect object count in object stream. I can't manage to copy the rest of the text from the GhostScript window, so I can't include it all here (except the above message that I typed-in by hand). I would like to find out where in the pdf file is the error, but don't see how to. I've recompiled the sources in debug mode, but although I can break-point on the above error message, understanding the code is not very easy. Even if the unbalanced >> is true, why can't GhostScript continue in spite of this error? Recovering from such an error should be easy.
In general Ghostscript will continue to process PDF files after errors, when this is possible. Note that you have quoted two faults, the first is an unbalanced dictionary mark (>>) the second is an incorrect object count in an object stream. These may occur in the same place, or may not. Object streams are a method for compressing additional types of objects in a PDF file for greater overall compression and smaller file size. An object stream starts with an index of objects and their byte offset within the stream. Unlike 'normal' PDF objects, these are not preceded by their object definition (eg 2 0 obj), but are simply the contents of the objects, run together. It can be difficult to know where one object stops and another starts. We can tell that something is wrong, but not necessarily whether it is the content or the index which is incorrect. We can't scan the content looking for '<index> <generation> obj...endobj' constructions to rebuild the index, which can be done for damaged xref tables, because the content of an object stream doesn't contain these markers. Now, as to where the error is, if you run GS with '-dPDFDEBUG' on the command line you should be able to see from the GS window which object it is processing when the error occurs. Since the object stream is compressed, it would be hard to fix it, and in order to 'see' the problem you will have to decompress the content of the object stream. That's about all that can be said without looking at the actual PDF file. If you'd like someone to look at it, you'll need to attach it to this bug report. If you want you can mark it as private immediately after you attach it, which will prevent anyone except Artifex employees and contractors from accessing it.
Created attachment 4766 [details] bug_balanced.pdf
Alex, Thanks for the useful answer. I've uploaded the file for examination per instructions. I note that GhostScript cannot read the second and following pages, while Acrobat does so without a hiccup. Regards Harry McKame
Harry, it looks like this may be a bug which has already been fixed. When I run the PDF file through the most recent revision of Ghostscript on my Windows box here it completes without complaint. You are correct that Acrobat also does not complain, and usually if it 'fixes' a file it offers to save it when you close the file, which it doesn't do in this case. I don't know exactly how you are invoking Ghostscript, but running gswin32 on Windows and dropping the file I can see all 6 pages. We are doing a new release of Ghostcript right now, if release candidate 2 proves satisfactory it should be released on 1st February (West Coast US). Binaries should be available for download pretty much immediately after release. I'd suggest you either pick up the new version then or, if you are comfortable with recompiling Ghostscript from source, pull a copy of the latest sources from the Ghostscript Subversion source repository. If this doesn't resolve the issue for you please feel free to reopen the bug.
I've downloaded and compiled version 8.64 and have tried it with the attached file. The results are half-encouraging: The error doesn't arrive any more in gswin32.exe, but an error still arrives in gsdll32.dll! By breakpoint on gsdll_stdout(), I've accumulated the following error text (which might be a bit mangled as regarding end of lines): While reading gs_res.ps: Error: /rangecheckes.ps: in --getinterval--s.ps: Operand stack: (gs_res.ps) (C:\\Program Files\\GhostScript\\ghostscript-8.64\\Resource) () 0 1 Execution stack: interp_exit --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- Dictionary stack: --dict:773/1123(G)-- --dict:62/200(L)-- --dict:773/1123(G)-- --dict:165/251(G)-- --dict:773/1123(G)-- --dict:23/40(ro)(G) --Last OS error: No such file or directory Current file position is 11413 251(G)-- --dict:773/1123(G) Unrecoverable error: undefinedt OS error: No such file or directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 in .uninstallpagedevice finedt OS error: No such file or directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 Operand stack: gs_res.psedt OS error: No such file or directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 C:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 C:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 0:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 1:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory Current file position is 11413 251(G)-- --dict:773/1123(G) 7 Further info: I've in the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.64" the following values: GS_DLL: C:\Program Files\GhostScript\ghostscript-8.64\bin\gsdll32.dll GS_LIB: C:\Program Files\GhostScript\ghostscript-8.64\lib;c:\program files\GhostScript\fonts;C:\Program Files\GhostScript\ghostscript-8.64\Resource I've no other subkeys than 8.64 under "HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript". Your input will be appreciated.
I'm afraid that looks like a problem compiling the sources, GS appears to be complaining that it can't find gs_res.ps. You haven't stated the command line you are using so its difficult to be sure what is going on. You can check and see if the file is present in /gs/Resource/Init/gs_res.ps (which it should be), but this file is supposed to be compiled into the executable in a ROM file system. As an experiment, in the command line window, set GS_LIB= and then try launching gswin32 from that command line window, not the GUI. I suspect there may be some problem with your installation and this 'may' narrow it down. You could also try running some of the files in the 'examples' folder, and perhaps some other PDF files if you have any, just to check whether your installation is working at all.
I'm afraid that my compilation was ok as regarding gswin32.exe, but not for gsdll32.dll - it is totally non-functional. As all my knowledge about compiling ghostscript is entirely contained in the string: nmake -f psi\msvc32.mak MSVC_VERSION=6 DEVSTUDIO="C:\Program Files\Microsoft Visual Studio" I have no idea why the above did miscompile my gsdll32.dll. But I wonder if you could point me to a working 8.64 Windows binary release, please ?
I'm afraid there doesn't seem to be a binary release for Windows yet. Are you really using Microsoft visual C 6 ? I presume that's the original version of Microsoft Visual Studio, released back in 1998 and superseded by Visual Studio .NET in 2002 ? I would try : nmake -f psi/msvc32.mak clean nmake -f psi/msvc32.mak which should rebuild everything for you, and should auto-detect the version of VC++ based on the version of nmake. (You may need to run the msvcvars.bat file in order to get the PATH environment variable correct so that Windows can find the build tools) Failing that, there is normally a binary release available soon after the sources are posted, but they were only released yesterday.
1. I don't find msvcvars.bat anywhere in the versions 8.64 or 8.63 (or anywhere on my hard disks). 2. I do have VS6 installed, but also VS2005. "nmake -f psi/msvc32.mak" manages to abort VS2005 on the first compile of .\base\genarch.c : NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\bin\c l.EXE"' : return code '0xc0000135' It seems like I must wait for the binary release. It should perhaps be noted somewhere that : a. The 8.64 source release doesn't correctly build gsdll32.dll on VS6, b. that it provokes an abort in VS2005, and that c. msvcvars.bat is missing.
I built 8.64 with MSVC 6 and MSVC 8. The command line I used (from a MS-DOS prompt) to build with 6 was: vcvars32.bat nmake -f psi/msvc32.mak MSVC_VERSION=6 > make6.log 2>&1 I will attach the 'vcvars32.bat' from my system in case that helps. This is what was created automatically when I installed Visual Studio 6. Note that for MSVC 8, the batch file that sets up the environment variables is vsvars32.bat (also created automatically during the install).
Created attachment 4777 [details] VCVARS32.BAT Sample vcvars32.bat from my system (installation directories may vary).
1. msvcvars.bat is (or was) part of the Visual Studio distribution. When executed in a command line window it configures the environment to run the Visual Studio tools from the command line. I could have the name of the batch file slightly wrong, but it was something like that. 2. I'm running Visual Studio 2005 on my PC and it builds the Ghostscript 8.64 release correctly. In VS 2005 you can open a command prompt properly configured from Start->Programs->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt
Thanks for the correction Ray. THe vsvars32.bat file can be found (on my installation of VS 2005) in \Program Files\Microsoft Visual Studio 8\Common7\Tools. I can't find any reference in the help for the quoted error (0xC0000135) I'm afraid.
I've followed all the directions and have successfully created the release using VS2005, with the result that now both gswin32.exe and gsdll32.dll don't work at all. I think I'll therefore wait patiently for the binary release for Windows before deciding if my bug has or has not been corrected in 8.64. Thank you for all your efforts in trying to get me going. I remark that I previously did compile 8.63 from the sources without any problem, and without any need to contact you. However, I am now for some reason unable to produce a viable 8.64. I suspect that some file(s) are missing, but will know more when I'll compare my compiled release with the future official release.
Further news: I've installed the 8.64 binary release. The result is that all the pdf files I've tried now work in BOTH gswin32.exe and gsdll32.dll, except that ... the problematic pdf attached here is the only file I've found that does work in gswin32.exe, but NOT in gsdll32.dll !
Hmm, I'm puzzled by what you are saying here. gswin32.exe is not a complete stand-alone application, it uses the gsdll32 DLL which, contains the actual interpreter code, to do most of the work. So I'm a bit puzzled as to how gswin32.exe works but gsdll32.dll doesn't. Its also not clear how you are testing the file with gsdll32.dll, since this isn't an executable. Is this being used from within your own application ? What do you mean when you say that the file 'doesn't work' with gsdll32.dll, do you get an error message or something else ? If you are using the DLL from your own application, are you absolutely certain you are using the correct DLL ?
gsdll32 is used by my program, and you're quite right to be puzzled - my test program for this file was in error. I've corrected the error, and my final conclusion is that the bug reported in 8.63 is definitely resolved in 8.64. I thank you for your outstanding support.