ghostscript gets stuck when trying to process attached PDF (created by ghostscript itself). The behavior does not seem to be driver dependent - it does the same if I use tiffgray driver. gswin32c -sDEVICE=jpeg -sOutputFile=c:\temp\gray.jpg -r300 -sPAPERSIZE=letter -dBATCH -dSAFER 05.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 15. Page 1 Loading NimbusRomNo9L-Regu font from C:\Program Files\ghostscript\fonts/n021003l .pfb... 2328496 902823 1597584 303349 3 done. Loading NimbusMonL-Regu font from C:\Program Files\ghostscript\fonts/n022003l.pf b... 2328496 952298 1597584 304629 3 done. -that's all that happens - it gets stuck here and waits forever...
Created attachment 1834 [details] pdf input file
Interesting enough the linux x86 8.53 x11 device is also spending a lot of time to render it (I am going to interrupt it rather than wait, but it does seem to be taking too long than it should). gdb says it is doing scan_contour(). hope it helps. 0x0821963f in scan_contour () (gdb) bt #0 0x0821963f in scan_contour () #1 0x0821a086 in add_y_list () #2 0x08218b4c in gx_general_fill_path () #3 0x08218f7a in gx_default_fill_path () #4 0x08072de1 in grid_fit () #5 0x080730c5 in gx_ttf_outline () #6 0x08068ee9 in append_outline_fitted () #7 0x08068448 in gs_type42_append () #8 0x080667b6 in type42_finish () #9 0x08066689 in type42_fill () #10 0x080665bc in ztype42execchar () #11 0x080b060b in interp () #12 0x080aebf3 in gs_call_interp () #13 0x080aeafb in gs_interpret () #14 0x080a6c3d in gs_main_interpret () #15 0x080a7552 in gs_main_run_string_end () #16 0x080a73cd in gs_main_run_string () #17 0x080a95d2 in run_string () #18 0x080a954d in runarg () #19 0x080a9366 in argproc () #20 0x080a81ab in gs_main_init_with_args () #21 0x0804adad in main () (gdb) When run with -dDEBUG, here is the backtrace, and the last few lines of the debug: 0x0822f0bc in gx_flattened_iterator__next () (gdb) bt #0 0x0822f0bc in gx_flattened_iterator__next () #1 0x0821963f in scan_contour () #2 0x0821a086 in add_y_list () #3 0x08218b4c in gx_general_fill_path () #4 0x08218f7a in gx_default_fill_path () #5 0x08072de1 in grid_fit () #6 0x080730c5 in gx_ttf_outline () #7 0x08068ee9 in append_outline_fitted () #8 0x08068448 in gs_type42_append () #9 0x080667b6 in type42_finish () #10 0x08066689 in type42_fill () #11 0x080665bc in ztype42execchar () #12 0x080b060b in interp () #13 0x080aebf3 in gs_call_interp () #14 0x080aeafb in gs_interpret () #15 0x080a6c3d in gs_main_interpret () #16 0x080a7552 in gs_main_run_string_end () #17 0x080a73cd in gs_main_run_string () #18 0x080a95d2 in run_string () #19 0x080a954d in runarg () #20 0x080a9366 in argproc () #21 0x080a81ab in gs_main_init_with_args () #22 0x0804adad in main () (gdb) ============= .... /R11 9.96 Tf %Resolving: [13 0] %Resolving: [11 0] 6 0 Td [ (\026) -2.31198 (\002) -2.31198 (\027) -2.31198 (\030) -2.31198 (\031) -2.31198 (\032) -2.31198 (\002) 600.098 ] TJ /R9 9.96 Tf %Resolving: [13 0] %Resolving: [9 0] 42 0 Td ( ) Tj /R11 9.96 Tf %Resolving: [13 0] %Resolving: [11 0] 6 0 Td [ (\033) -2.31198 (\034) -2.31198 (\035) -2.31198 (\003) -2.31198 (\002) ] TJ /R9 9.96 Tf %Resolving: [13 0] %Resolving: [9 0] 30 0 Td [ ( ) -2.40905 ( ) ] TJ /R11 9.96 Tf %Resolving: [13 0] %Resolving: [11 0] -276 -11.28 Td [ (\b) -2.31198 (\027) -2.31198 (\036) -2.31198 (\032) -2.31198 (\037) -2.31198 ( ) 600.098 ] TJ ===================
OTOH, xpdf on linux is happy but renders it fine.
Also with display device on Windows got assertion failed in gxpflat.c ln 454 this->i < 1 << this->k
Can't reproduce 'assert' with Developer Studion debug session. Likely the effect isn't deterministic.
A fixed overflow happens in gx_curve_log2_samples while computing 'd'. Source data x0 = -2147483648 == 0x80000000 isn't good.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-December/005837.html Patch to GS_8_1X : http://ghostscript.com/pipermail/gs-cvs/2005-December/005838.html
One more patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-December/005846.html