**** Problem Many landscape PDFs fail to be read by ghostscript. **** How to reproduce Create a Postscript file: $ cat > cat test.ps < EOF %! << /PageSize [ 842 595 ] >> setpagedevice showpage EOF Convert to PDF: $ ps2pdf test.ps Read the new PDF with ghostscript: $ gs test.pdf AFPL Ghostscript 8.53 (2005-10-20) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Error: /rangecheck in --initgraphics-- Operand stack: --dict:4/4(L)-- --dict:5/5(L)-- --nostringval-- --dict:46/46(ro)(L)-- --dict:5/5(L)-- --dict:1/2(L)-- --dict:47/56(ro)(L)-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- 2 7 %oparray_pop 7 7 %oparray_pop --nostringval-- 7 7 %oparray_pop --nostringval-- Dictionary stack: --dict:1125/1686(ro)(G)-- --dict:2/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:105/127(ro)(G)-- --dict:258/347(ro)(G)-- --dict:20/24(L)-- Current allocation mode is local Last OS error: 2 AFPL Ghostscript 8.53: Unrecoverable error, exit code 1 **** Discussion This seems to be triggered by the auto landscaping when specifying the pages size with the long side first. Setting the page size to [ 843 595 ] or similar sizes close 842 by 595 causes no error. Also happens with current GPL 8.50. Acroread has no problem with this PDF, it dispays the page landscape as expected.
Created attachment 2073 [details] gs 8.53 x86 linux generated pdf The issue does not happen on gs8.53 x86 linux. Here is the pdf that gs8.53 x86 linux generates, and it displays fine. Please attach the solaris-generated pdf for comparison
Created attachment 2075 [details] test pdf Note the first attachment crashes too.
I have no problem with the 2nd attachment with gs 853 x86 linux either. Seems to be Sun-specific or specific to your build. At this point it would be useful to include OS version, patch level, and compiler used (sun workshop or gcc), and whether gs was built for 32-bit or 64-bit.
Solaris 8, patch recently (this year) 117351-32, Sun Studio 10. Are you using A4 paper? It's more than coincidence the size is exactly the default paper size rotated. Thank you for your feedback, it's possible there is a compiler problem or maybe an endian issue. I will try rebuilding and see if I can find anything.
The two pdf's differ only by the expected stuff (creation/mod date in the pdf, etc). I am not sure paper size is relevant - "gs test.pdf" just launches a portrait window which immediately get replaced by a landscape one. (if you are running X). Can you try "gs -dDEBUG test.pdf"? It should output some info as it processes the pdf file. Just to be sure, your gs does work normally otherwise, right? e.g. displaying the colorcir.ps or tiger.ps shipped in the example directory, etc.
> The two pdf's differ only by the expected stuff (creation/mod date in the > pdf, etc). So as reported it's the PDF interpreter not the PDF. > I am not sure paper size is relevant - "gs test.pdf" just launches > a portrait window which immediately get replaced by a landscape one. Paper size is almost certainly relevant, in what way we don't know. 2nd time: Are you using A4 paper? > (if you are running X). Fails if device is X or not. > Can you try "gs -dDEBUG test.pdf"? It should output > some info as it processes the pdf file. I have run with page size [842 595] and [842.1 595] and compared the output. The interesting difference is: [842.1 595.0] /.MediaSize vs: [595.0 842.0] /.MediaSize So it is definitely treating the page size differently when landscape of A4. This is like a real postscript printer doing an auto rotate. > Just to be sure, your gs does work normally otherwise, right? e.g. displaying > the colorcir.ps or tiger.ps shipped in the example directory, etc. Yes.
It's not related to default paper size, any "known" paper size cause same. Known seems to be those listed in Use.htm#Known_paper_sizes.
I am not sure what "are you using A4 paper" means - but if you are asking if I had changed gs default papersize in "gs_init.ps" to a4, the answer is no. In any case, gs -sDEFAULTPAPERSIZE=a4 ... works correctly also. I can use a solaris 8 box at work tomorrow, but most probably it only have gcc.
likely related to bug 689794 - both are orientation-related and triggered by non-portrait-orientation pdf's, and failure with rangecheck in init-graphics. Possibly sunstudio default to do gcc fast-math equivalent? Suggest dropping optimization level in building with sunstudio as a workaround to see if it improves.
Ghostscript developers don't have access to Sun Studio but the bug 689794 seems similar to the reported problem. The latter is now fixed by the rev. 11949. Please re-test the current development version on Sun Studio. Feel free to reopen the bug report if the problem persists.