Look at the PDF Here: http://photos.imageevent.com/jayspics/pdf/postbookcomp.pdf On Page #7 it just craps out and just sits there waiting with no response. In Linux, I have to Control-C it to get out and in Windows it stops responding. Command run is: gs postbookcomp.pdf This pdf runs just fine under Adobe. I am wondering what is the issue here and if there is a workaround or fix.
Created attachment 4857 [details] postbookcomp.pdf. I have attached the file that is giving errors. I have attached the file that is giving errors.
The PDF file does not 'run just fine' with Acrobat. The offending page generates an error 'Cannot extract the font JVTZAK+HelveticaNeueLTPro-Lt. Some characters may not display or print correctly'. on page 7. So there's something wrong with the PDF file. However I don't think this is actually a problem. There is an extremely large image (1547x969, 1 component ICC) with interpolate set to true on that page, and GS seems to be spending a lot of time trying to render it. Running with the -dNOINTERPOLATE switch the page displays extremely quickly. So its simply a quality issue, the GS interpolation is spending a lot of time trying to interpolate the image for maximum quality. While a performance improvement to interpolation would be nice, this is not a bug.
There should be some kind of checks in gs so it will open. I have left this PDF trying to open for over 40 hours and it stalls out with a very load on the CPU. I am willing to wait for it to open, but I do not want to add - dNOINTERPOLATE to the files. Most users wont even understand this. I just want to open the file normally. -dNOINTERPOLATE is not in the man page. There should be some type of error message or way to pass the page up instead of stalling. This is a PDF that a customer made and is valid. I believe you need to look at this further. An incorrect font shouldn't be a reason.
The file does open, I believe, though I haven't tried waiting long enough to find out. Its clearly going to take a very long time. The action of interpolation is described in the reference manual as 'device dependent', so its pretty much up to us what we do. I did debug the file and it is spending a lot of time in the interpolation code (its a very big image), and the fact that turning off interpolation renders quickly is a pretty big clue. -dNOINTERPOLATE is described in the Ghostscript documentation in /gs/doc/use.htm You can skip a page from the PDF if you wish, or you can disable interpolation, both are described in the documentation. The PDF is basically valid, and renders quickly if you don't try and interpolate it. As far as I can tell from a quick inspection GS does not 'stall' it simply takes a long time to perform the requested operation. To add insult to injury, the page in question also uses transparency, so there's another very large image laid over the top of it and composited with it. (Ray, I don't get the correct output with this page anyway, would you check with the soft mask branch please ?) The damaged font is a different issue, please note that it is not Ghostscript complaining about the font, but Adobe Acrobat 9. A damaged font is very often a good reason to abort a job as the PostScript font subsystem (which is the same in many respects as PDF) is allowed to expect well-formed fonts and does minimal checking in order to increase performance. You asked for a work-around, you have one; use -dNOINTERPOLATE. I don't understand why you are unwilling to use this, in the general case it makes no difference since most images do not specify interpolation. Unless you want very high quality output, turning off interpolation even for those images which do specify it will make no significant difference to the output either. I won't set this back to closed, I'll leave that for support to decide, though I see no reason to describe this as a bug. I have, however set the priority back to 3. P1 and P2 are reserved for Artifex commercial customers.
I am changing this to 'enahancement' and assigning to Michael. This will probably be helped a LOT by the new ICC workflow (it's a good test file). Also I will test with the smask_work branch to see if the rendering is done correctly with that soon to be committed w.i.p. Note that this may have been made worse when Michael changed the image interpolation over to interpolating in the source color space (then converting the colors to the device color space). This means that there can be many more color conversion operations, which we currently do one-by-one. In any case, as an enhancement, it won't get HIGH priority attention. I am also marking this 'bountiable', but hopefully anyone considering this as a bounty work will at least consult with us about the ICC workflow design so that a fix will be compatible with the future.
This is actually the same issue as #690351. The reason the interpolation takes an immensely long time is because the image in the soft mask group gets scaled twice. *** This bug has been marked as a duplicate of bug 691157 ***