Using convert to make a PNG thumbnail from a pdf file e.g. convert -scale "640" -density 150x150 -colorspace RGB seite5.pdf seite5.png /usr/bin/gs -q -dBATCH -dMaxBitmap=300000000 -dNOPAUSE -dSAFER -sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g2421x3306 -r150x150 -sOutputFile=/tmp/magicAGsFTE -- /tmp/magicapA8us -c quit doesn't work. gs does not return any output. the pdf file is available here: http://pdf.selfip.net/seite5.pdf
I used: time bin/gswin32c -dBATCH -dMaxBitMap=300000000 -dNOPAUSE -dSAFER - sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g2421x3306 -r150x150 - sOutputFile=xx.pnm ../test_files/688363.pdf -c quit Results: real 373m33.00s user 367m52.56s sys 0m16.89s That does seem a little excessive.
Interesting that this hangs for a long time on an 'S' operation at step 20114 (using -dPDFSTEP). I will check where this is going with the debugger. I suspect shaded fill but that is just a guess.
Customer field is reserved for Artifex OEM customers.
retest
I ran a retest on this file since there have been several improvements which might affect the file execution time. File aborted after 20 minutes. The file is spending a huge amount of time inside of intersect_al. Changing assignment to the person to the implementer of this routine.
Created attachment 2158 [details] seite5.pdf A local copy of the test file.
intersect_al was factored out from Peter's code. With using visual trace and a C debugger one can see that the problem happens due to 'stroke' generates a lot of sector-like spot segments, which have centers at a small distance, so that the path contains a big number of lines, which differ in a small angle and have multiple intersections, which appear close each to another. One can see that on Windows running with -TF and specifying ScaleX=20 ScaleY=20 in Windows\gs_vdtrace.ini. IMHO the stroking algorithm needs an improvement. We also noticed that forcing the scanline angorithm appears some faster, but still not satisfactory.
Created attachment 2159 [details] vt.bmp.zip The stroke outline snapped with visual trace -TS option (a fragment that could fit into window). gs_vdtrace.ini parameters for taking it are : [VDTRACE] OrigX=600000 OrigY=1500000 ScaleX=300 ScaleY=300 ShiftX=0 ShiftY=0
This problem happens with GraphicsAlphaBits>1 only, due to a reason explained in the comment in gspaint.c ln 370 : * The alpha-buffer device requires that we fill the * entire path as a single unit. Otherwise each stroke spot segment is painted separately, so as it doesn't need to compute so many line intersections.
A work around for this is to use 4x resolution, then 'convert' the file down to the desired resolution (and don't use GraphicsAlphaBits > 1) The time required to make a 600 dpi ppm with gs was 15 seconds, and the convert time was 23 seconds (on my 3GHz P4). The command lines I used were: bin/gs -sDEVICE=ppmraw -r600 -g9684x13224 -sOutputFile=seite5-600.ppm seite5.pdf convert -resize 25% seite5-600.ppm seite-150.ppm
*** This bug has been marked as a duplicate of 690531 ***