The page attached to this bug report (p18.pdf) provokes the following problem with GhostScript, on Windows 2000 and Windows XP : The command used is : gswin32c -sOutputFile#p18.tif -I"c:\winnt\fonts" -dNOPAUSE -dBATCH -sDEVICE#tiffg4 -r300 p18.pdf The CPU is used at 100% and the memory is being used increasingly, for a long time, until the program ends with the following message : AFPL Ghostscript 8.54 (2006-05-17) 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 Loading TimesNewRomanPSMT font from c:\winnt\fonts/Times.ttf... 2576176 933929 2451880 1096580 3 done. Loading ArialMT font from c:\winnt\fonts/Arial.ttf... 2582368 965005 2887916 1469140 3 done. Loading TrebuchetMS font from c:\winnt\fonts/Trebuc.ttf... 2582368 977413 3454836 2079958 3 done. Error: /VMerror in --stroke-- VM status: 3 2177334 2295388 Current allocation mode is local AFPL Ghostscript 8.54: Unrecoverable error, exit code 1 There is no file produced while converting in TIFF. The conversion to PostScript ends with a file being created, but incomplete. This output could maybe be used to check the problem.
Created attachment 2779 [details] Page causing GhostScript to use increasing memory and to stop
Do you have reproduced the problem? Thanks in advance, Francois
Have you any news for us?
Created attachment 2844 [details] screenshot.png Adobe Acrobat Reader 7.0 on my 64 bit Linux box fails in a similar way (see screenshot.png). It initially loads the PDF okay, but when I try to zoom in it consumes and more and more memory (I killed it at 2 gigs).
The file contains the following fragment: [0.075756 0.028408 ] 0 d -907.772 786.549 m % Repeated 128 times 9646.9238 -15043.7656 l % with small variations. S i.e strokes a dashed line with 32M dashes. No wonder the file needs so much memory. IMHO the file is invalid.
Some additional DEBUG (PDFSTEP output): 4 0 0 4 0 0 cm step # 201335 ? [ step # 201336 ? 0.075756 0.028408 ] step # 201337 ? 0 d step # 201338 ? -907.772 786.549 m step # 201339 ? 19646.9238 -15043.7656 l step # 201340 ? Then the sequence of 'm' and 'l' repeats as Alex mentions, then finally the 'killer' processing starts with: S step # 201495 ? _____________________________________________________________ Does it make sense to eaxmine the dash settings and when the entire dash sequence is less than 2 device pixels, turn it into a solid line ? Also the order in the graphics library must be converting the entire line to dashes, even if it is outside the clip path. At 300 dpi, the dash pattern implied by: [ .075756 .028408 ] is 1.7367 device pixels. At this same scale, the stroke segments deltas are 175911.5 in X and 263838 in Y. The entire page (A4) is only 2480x3508 pixels. Ignoring dash expansion outside the clip path (accumulating position, but don't add individual segments to the path) would optimize this somewhat. ______________________________________________________________ With the following (experimental) patch, I was able to convert the file to tiffg4 at 300 dpi in 23 seconds using less than 10Mb. *** lib/pdf_draw.ps Thu Jun 21 19:36:18 2007 --- ./pdf_draw.ps Sat Jul 7 11:15:20 2007 *************** *** 287,293 **** /i { 1 .min setflat } bdef /J /setlinecap load def ! /d /setdash load def /j /setlinejoin load def /w /setlinewidth load def /M { 1 .max setmiterlimit } bdef --- 287,298 ---- /i { 1 .min setflat } bdef /J /setlinecap load def ! /d { 1 index length 0 gt { ! 1 index 0 exch { add } forall ! dup dtransform pop ! 2 lt { exch pop [ ] exch } if % set to solid ! } if setdash ! } bind def % /setdash load def /j /setlinejoin load def /w /setlinewidth load def /M { 1 .max setmiterlimit } bdef _______________________________________________________________________ Ressigning to Igor to consider making the optimizations in the graphics library where they will benefit PCL as well as PS and PDF.
Actually, thinking about it a bit more, it probably suffices to treat any dash pattern with the largest 'space' being less than one pixel since the 'any part of pixel' painting rule will effectively paint all pixels. Also, the file probably isn't really 'invalid', but probably just a scaled down version of a map that was intended for rendering much larger.
Reassigning to Alex for patch review. Graphics library optimizations can be left to Igor (reassigning the bug back to him then after the consideration of the patch)
This approach doesn't work because CTM can change between setting the dash pattern and drawing the line. Testing shows significant regressions.
OK, so I guess what is needed is to put the logic down in the C code when the line is drawn (to ignore small dashes that would just be solid anyway). Thanks, Alex, for pointing out the issue with doing it when 'setdash' is invoked.
Sounds like a graphics lib issue.
Solved in: commit dcc172feb018bfe0613f90ce76ce25dd1eafe3ce Author: Robin Watts <robin.watts@artifex.com> Date: Tue Oct 1 17:52:43 2013 +0100 Bug 689098: Only dash paths when the dashing would be visible. If the ctm doesn't expand the dash lengths to be > 1 pixel, then they can't be seen, so don't bother. Many thanks.