after compiling GhostScript 8.51 we tested some InDesign binary (!) Files on it, and recognized a strange behaviour due to handling of binary operands (for example 0 <binary value>translate) Ghostscript rips empty(white) pages (raw, jpeg, tiff etc.) Same File on PC-Windows Distribution is processed properly. Same File ripped on GhostScript 8.11 on AIX platform is processed properly
Please attach a sample file.
Created attachment 1614 [details] EPS Data from InDesign CS 3.01, saved in binary mode
I cannot reproduce this problem on GNU+Linux for AMD64 or Alpha, So it looks like a platform-specific problem. Unfortunately, I don't have access to an AIX box nor know about any ISP that offers AIX shell accounts. You can try to debug on your own and submit a patch or provide a ssh access to a Ghostscript developer.
Other than providing AIX shell accounts, another alternative would be if the result of ps2pdf on AIX from both versions of gs can be attached? Just saying it rip to white is not very useful, nor the wild guess(?) about possible problem with binary operand. If it doesn't rip correctly, there is a good chance that pdf generation would also be affected.
Created attachment 1621 [details] AIX RIP Behaviour, 64Bit Plattform, tested on devices pdf, eps Hello, I attached a PDF and a PS Dokument and the original EPS Data. Neither the PDF nor the PS Dokument is created correct. Help would be appreciated. Dietmar Müller
The broken eps is quite useful. Comparing to eps generated on x86/linux, all the drawing instructions were there, but the co-ordinates are wrong. Many of the y co-ordinates instead of 5000 to 7000, becomes -3000 to -1000. So there is an integer overflow, or signed/unsigned-ness problem somewhere. The drawings are "off-screen", but still in the eps. I haven't got round to take the pdf apart, but it doesn't look to be without content, so my guess is that it would show the same problem as the eps (i.e. drawing outside the page boundary).
Created attachment 1624 [details] x86/linux generated eps for reference to my the last comment. Here is a sub-set of the diff - the way it went wrong on AIX is quite clear - the y-co-ordinates goes from 7000-ish to -1000, 6000 to -2000, 5000 to -3000, etc. (the x co-ordinates never go beyond 4000, but it is possible that both are broken). 225c225 < 2998.84 7308.4 m --- > 2998.84 -1110.6 m 242c242 < 1026.44 6115.36 m --- > 1026.44 -2303.64 m 252c252 < 1061.32 6325.6 m --- > 1061.32 -2093.4 m 274c274 < 1682.12 6327.04 m --- > 1682.12 -2091.96 m 286c286 < 1811 6291.04 m --- > 1811 -2127.96 m 298c298 < 2055.8 5945.44 m --- > 2055.8 -2473.56 m 316c316
BTW, at the point, I think it is probably *not* a 64-bit problem, but a signed/unsigned char problem. So it might be worth trying to reproduce the problem on a platform that has different unqualified char signedness from intel - e.g. PPC/linux (sourceforge's cf has one), which may be a bit easier than getting hold of an AIX... Another suggestion: if you are using gcc to build ghostscript, see if adding '-fsigned-char' or '-funsigned-char' makes any difference to the result. (these two switches explicitly declares unqualified char as unsigned or signed when none is indicated; one of them gives the intel behavior, the other PPC one, - so one of them may cure the problem - don't do both!). Or look at your compiler's manual for the equivalent option if you are using AIX's own cc.
Ghostscript compiled by GCC 2.96 on GNU+Linux, x86 works correctly with -fsigned-char or -funsigned-char .
All the instances of brokenness in the epswrite result are of the form of replacing the y co-ordinate of a drawing instruction with -(8419-y) exactly. There is only one other difference: a clip path declaration at the beginning is missing. 8419 is the page height in 0.1pt's in A4 size - the height of an A4 page is about 842pt. All the drawing instructions are in units of 0.1pt in the eps. So essentially, all the drawing instructions are drawing things exactly one page below from where they should be.
Recompiling gcc with the options signed and unsigned char gave the same behaviour. Dietmar Müller
Dietmar: Although the symptom is a bit more specific (drawing exactly one page height below), it is difficult for the ghostscript people without an AIX box; so you probably have to do a bit of more debug work... the primary way now is probably try to find out where it differs on AIX compared to another platform, ideally with the same version of ghostscript. So I would suggest you do: gs -dDEBUG -sDEVICE=epswrite -sOutputFile=/dev/null -dBATCH -dNOPAUSE <file> and compare the screen-dumped debug messages for AIX and another platform. If there is no difference, you might have to go a bit further and do 'make debug' (see "doc/Make.htm#Debugging") to build the ghostscript binary with debug info and compare. (if you don't have another platform handy, just >& to a file, zip it up, and attach).
I've got an account on AIX 5.3 box -- without gcc. GS works just fine when it's compiled with VisualAge C, v.6 using default options: configure; make So we are entering an wonderful world of compiler dependency. To reproduce the problem we need to know: AIX version, GCC version, and compiling options.
Created attachment 1633 [details] Debug output from aix
Created attachment 1634 [details] Output from linux - correctly behaviour
Dietmar: the debug output doesn't show anything interesting; you could try doing 'make debug' to build the debug-build of ghostscript (see documentation) and run the debug again with epswrite or pdfwrite or both. The AIX pdfwrite result earlier also turn out to be quite interesing, and differently broken compared to epswrite. Compared to the x86 result, the AIX pdfwrite output the clip path twice, and the 2nd time with wrong co-ordinates. -----wrong------------------- q 0.1 0 0 0.1 0 0 cm /R7 gs q 0 0 m 0 8419 l 5953 8419 l 5953 0 l h W n 0 0 m 0 8418.9 l 0 -5952.75 l 8418.9 0 l W n 0 0 0 1 K 0 0 0 1 k Q Q ----correct------------ q 0.1 0 0 0.1 0 0 cm /R7 gs q 0 0 m 0 8419 l 5950 8419 l 5950 0 l h W n 0 0 0 1 K 0 0 0 1 k q 10 0 0 10 0 0 cm BT /R9 72 Tf 1 0 0 1 73.7008 688.03 Tm -1.30078 Tw (Ein T)Tj 155.637 0 Td (est)Tj -155.637 -86.4 Td (zwo,)Tj 86.4 TL (drei,)' (vier)' ET Q /R10 gs 0 0.705078 0.875 0 k 1 i 3945.16 5192.4 812.047 812.047 re f Q Q ----------------
Created attachment 1653 [details] Debug Output Ghostscript compiled with "make debug"
Not much useful information in the debug outout... could you send using the debug build of gs, the result of both epswrite and pdfwrite with the additional switch "-ZPxg"? i.e. something like this: export GS_LIB=<where_lib_is> debugobj/gs -sOutputFile=/dev/null -sDEVICE=epswrite -ZPxg -q -dNOPAUSE \ -dBATCH inputfile > & debug.out
Created attachment 1654 [details] debugoutput: epswrite
Created attachment 1655 [details] Debug output PDFwrite
I mean with the original epsfile: debugobj/gs -sOutputFile=/dev/null -sDEVICE=epswrite -ZPxg -q -dNOPAUSE \ -dBATCH input_file.eps > & debug.out also, you need the debug build (i.e. 'make debug'), and with the "-ZPxg" switch. The top of the output should look like this: -------------- [x]initmatrix: [ 10 0 0 10 0 0] t_fixed: [ 0 0] [P]Clipping path: (path not valid) inner_box=(0,0),(6120,7920) outer_box=(0,0),(6120,7920) rule=-1 list.refct=1 list count=1 xmin=0 xmax=6120 rect: (0,0),(6120,7920) [x]initmatrix: [ 10 0 0 10 0 0] t_fixed: [ 0 0] [P]Clipping path: (path not valid) inner_box=(0,0),(6120,7920) outer_box=(0,0),(6120,7920) rule=-1 list.refct=1 list count=1 xmin=0 xmax=6120 rect: (0,0),(6120,7920) [g]gsave -> 0x8482bbc, level = 1 [g]gsave -> 0x84999bc, level = 2 [g]gsave -> 0x849a00c, level = 3 [g]gsave -> 0x840f2ac, level = 4 [g]gsave -> 0x840f8fc, level = 5 [P] 0x833e21c<0x0,0x0>:0: 0.0000 0.0000 moveto % #curves=0 last=0x833e21c [P] 0x833e260<0x833e21c,0x0>:0: 0.0000 7920.0000 lineto [P] 0x833e280<0x833e260,0x0>:0: 6120.0000 7920.0000 lineto [P] 0x833e2a0<0x833e280,0x0>:0: 6120.0000 0.0000 lineto [P] 0x833e2c0<0x833e2a0,0x0>:0: closepath % 0.0000 0.0000 0x833e21c --------------------
there is no output when we used the debug build with the command "debugobj/gs -sOutputFile=/dev/null -sDEVICE=epswrite -ZPxg -q -dNOPAUSE - dBATCH input_file.eps > debug.out". only with the -dDEBUG option information will be generated.
The -Z... switch only have effect on the debug build, which is a special compilation option. Instead of "./configure ; make", you do './configure ; make debug' and the new gs binary is built inside the "debugobj" sub-directory instead of the "bin" sub-directory of the source tree. See "doc/Make.htm#Debugging" inside the doc directory for explanation.
Created attachment 1656 [details] This is the right debug output due to eps
Dietmar: Strange as it might sound, but the latest debug trace (http://bugs.ghostscript.com/attachment.cgi?id=1656&action=view) doesn't show any problems. Could you see if the empty-page problem is exhibited by the 'make debug' gs binary in debugobj? Just to be sure. It is quite possible that the differently compiled gs binary works fine (although much slower and may spill out messages while running).
the binary in debugobj works fine but not the common binary in bin. This means the eps data is ripped well with debug-object. Also well in JPG, or PDF.
Hmm, the debugobj binary works fine, as I thought it could be... There is no much else anybody without your box/set-up might do, as the symptom disappears as soon as one tries to get more info out of it :-). For the time being I'd suggest you copying over the debugobj binary and use it for real if the speed doesn't bother you too much. In the long term, you might want to do these: (1) try varying compiler (switching from gcc to IBM's visualage, and vice versa; by setting env CC to the full path of either), and optimization level (from -O0,-O1, -O2, -O3, -O5 - by setting env CFLAGS before configure/make) and see if you get any difference. And if you can find a config that gives a non-debug binary that works, report back... (2) tell us more about your system: e.g. output of uname -a instfix -ivq oslevel -r lslpp -h bos.obj Your compiler version - depending on whether you are using gcc or IBM's xlC: gcc -v lslpp -l | grep 'xlC'
Priority 1 and 2 are for OEM customer bugs. Setting to P3.
I've got an account on IBM RS/6000 model 7011-200 with AIX 3.4 and gcc 2.95.3 . Default release builds of gs 8.51 and current HEAD (8.54) work just fine. Please provide more information about your system as indicated in the comment #27 . Please also check the value of CFLAGS evironment variable.
A bunch of crash causing bugs have been found in gs 8.54 on 64-bit platforms and fixed. Current development version has no known 64-bit issues. It is avalable by anonimous svn from svn co http://svn.ghostscript.com:8080/ghostscript/trunk/gs Although this problem has never been reproduced by Ghostscript developers, it is likely to be fixed in the current code. Feel free to reopen the bug report or submit a new one if the bug persists in the current development code or the upcoming 8.56 release.