Created attachment 124780 [details]
Attached pdf lets pdftops 0.45.0 work 2 1/2 hours on the conversion to Postscript on 64-bit Linux.
command: pdftops runsforever-poppler.pdf
Wed Jun 29 13:58:40 CEST 2016
$ pdftops runsforever-poppler.pdf
Wed Jun 29 16:28:46 CEST 2016
The original PDF is 10MB, the resulted .ps 67MB
Most pdf files can be converted withing few minutes with pdftops.
It looks like pdftops is looping somewhere or some recursion or loop is not implemented optimally.
Is it possible that this will be corrected in the near future?
STB H 14
This is an particularly "unfriendly" PDF.
It contains a vectorial map, the map shows several hundreds of trees, and each tree crown is drawn as hundreds of branches.
Apparently the trees are drawn as lineart.
According to valgrind, the majority of the time is spent calculating path intersections, i.e. in SplashXPathScanner::computeIntersections(...).
Not only pdftops is slow, but also okular, thus I have changed the component.
Created attachment 139603 [details]
valgring --tool=callgrind okular runsforever-poppler.pdf
I think this can be marked as a duplicate of 78728
Don't assign bugs to me. you remove them from the mailing list and people stop receiving the emails.
Are you sure pdftops slowdown has to do with SplashXPathScanner too?
AFAICS pdftops rasterizes the whole document, so this seems reasonable.
I am currently running pdftops inside valgrind, this may take some more hours ...
(In reply to Stefan Brüns from comment #5)
> AFAICS pdftops rasterizes the whole document, so this seems reasonable.
It tries very hard not to do that, but in some cases (like when there are transparencies that afaik are not supported in ps) it has to.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/57.