Bug 690351 - PDF does not render sPage #7 very slowly. Tried on Both Linux and Windows
Summary: PDF does not render sPage #7 very slowly. Tried on Both Linux and Windows
Status: RESOLVED DUPLICATE of bug 691157
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 8.64
Hardware: PC Linux
: P2 normal
Assignee: Chris Liddell (chrisl)
URL: http://photos.imageevent.com/jayspics...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-20 15:54 UTC by Jay
Modified: 2010-11-16 20:51 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
postbookcomp.pdf. I have attached the file that is giving errors. (3.66 MB, application/pdf)
2009-03-20 15:56 UTC, Jay
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jay 2009-03-20 15:54:40 UTC
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.
Comment 1 Jay 2009-03-20 15:56:15 UTC
Created attachment 4857 [details]
postbookcomp.pdf. I have attached the file that is giving errors.

I have attached the file that is giving errors.
Comment 2 Ken Sharp 2009-03-21 02:36:29 UTC
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.
Comment 3 Jay 2009-03-21 08:42:57 UTC
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.

Comment 4 Ken Sharp 2009-03-21 10:01:17 UTC
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.

Comment 5 Ray Johnston 2009-03-21 11:26:46 UTC
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.
Comment 6 Chris Liddell (chrisl) 2010-11-16 20:51:15 UTC
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 ***