sumatrapdfreader
"Please wait - rendering..." for infinite time
PDF File: http://ge.tt/16fRR1q2
This file correctly displays in adobe acrobat. If opened with sumatra, it shows "Please wait - rendering..." for an infinite amount of time.
Got the same result with Firefox. Surprisingly Edge managed to display the map.
In any case you should file this as a MuPDF issue (that's the rendering engine Sumatra uses) at https://bugs.ghostscript.com (be sure to specify the Affected Product as MuPDF).
ENR6.3-9(slow rendering).pdf Agreed that as far as SumatraPDF is concerned this is a MuPDF issue and needs to be reported there It would appear this Aero Chart file is not well adapted for general readers as it is seems to be vector based ~~but contains no~~ with layer control. There is no discernible text nor font. It looks as if it is intentionally restricted to limit usability. As GSV (using an older MuPDF) can quickly read the file, it can be exported to a more generic version 1.3 that will even though its slightly bigger, render more easily, in general viewers such as SumatraPDF.
modified file ENR6.3-9.pdf
@kjk This extensive vector format file is working (especially in acrobat) but not well ordered for general rendering by rasterising viewers such as mupdf (firefox ? etc.), I thus suggest this issue is file structure specific, thus a MuPDF issue, NOT a SumatraPDF code issue, since on removing the layering and reflowing the vectors it speeds up the render conversion in MuPDF / SumatraPDF.
@kjk the above file still hangs indefinitly in latest build (it may be worth adding a time-out setting for such cases ?)
I filed a bug against mupdf https://bugs.ghostscript.com/show_bug.cgi?id=701945 If they fix it, we'll incorporate the fix.
FYI: https://bugs.ghostscript.com/show_bug.cgi?id=701945#c2
As this (MuPDF) still stands today, the patch mentioned there does at least reduce the trouble until this one gets addressed by Artifex. Analysis writeup & patch at the link (MuPDF bugtracker).
What the patch does is basically watch the clock while rendering complex vector drawings and applying a rough heuristic deciding to forget drawing a metric ton of remaining vectors when a timeout has expired.
Cave canem: you're then looking at a patched mupdf library and the consequences that entails. I'm okay with that, but people differ and YMMV.
That's the current state of affairs AFAICT.
Thanks to the original OP (@claudiotam) for digging up that horror PDF: it has been added to my own test corpus which is used to dig up PDF nastiness. Hadn't encountered this type of behaviour before I ran into this report last year. 👍
@GerHobbelt Thanks for your efforts, MuPDF have a very variable track-record for such fixes sometimes hours other times a half decade, I have no idea how easy to create or even if @kjk would accept a pull request since the issue appears to be within MuPDF library jurisdiction.
Had another look after a long hiatus.
The problem is still there, also in bleeding edge mupdf.
https://github.com/GerHobbelt/mupdf/commit/911e445c4399191fb97e6ea406f22b71576ea4a7 is a rough patch to make it all work faster, but this is hacky: that commit is not clean (first two diff blocks are unrelated but part of the debug/investigation work today) but the TL;DR is: we disable creating a knockout blending image layer for direct PDF PATH (vector drawing) operations and only keep it for GROUPS: this reduces the pixmap create+blend+drop activity significantly and still renders a more or less decent image. Of course, this patch would not be strictly adhering to the rules as I now have all PATHs and TEXTs render directly in the base pixmap, without any knockout blending being applied to the mix.
I have not been able to find a better way to cope with this; for me it is more important to have decent render speed than (pedantic?) standards adherence, where the user would simply consider their machine dead: current mupdf codebase renders this animal in > 5 minutes on a AMD Ryzen 3700X (plenty RAM), where the render action was aborted by me before completion, to a ~5 seconds with this patch applied (haven't timed it precisely; was busy getting this beast stable again).
TL;DR:
still no final solution from Artifex for this; if you want to survive PDFs like this one, you either need a patched mupdf lib (that's otherwise risking non-compliance elsewhere thanks to the (slightly) reduced capability) or an outer hard-kill mechanism to unblock the page render.
Notes
At least my current patch is better than what I had before, as that completely nuked the rendered image. Now at least I get to see something reasonable. 😄
🤔 I'm wondering if & how I can detect animals like these before "reasonable render time" is running out, and then tweak some internal render settings to make it behave in a timely fashion. Add that to this hacky patch and we might have something that's usable in the wild? (At least it would for my purposes...)