Bug 1403009

Summary: Printing PDF's takes 30 seconds o just prepare a file for printing
Product: Red Hat Enterprise Linux 8 Reporter: Oliver Ilian <oliver>
Component: popplerAssignee: Marek Kašík <mkasik>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.1CC: crungeho
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-01 07:27:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Oliver Ilian 2016-12-08 21:21:16 UTC
Description of problem:
Evince on RHEL 7 and up to Fedora 24 takes a long time to prepare a print of a PDF file. It hangs for at least 30 seconds before the print is started. If I print the PDF from Chrome or Firefox preview, it takes ~20 seconds to completely print the file

It is a 35 MB file with an org chart, and only page 1 is printed 

Version-Release number of selected component (if applicable):
evince-3.14.2-17.el7.x86_64 and higher

How reproducible:
any time

Steps to Reproduce:
1. open a big file in evince (it takes very long before the preview is loaded at all) 
2. print the file (does not matter if it is a local USB connected printer or a cups network printer)

Actual results:
Evince shows a progress bar that it prepares the print for about 30 seconds, without the bar moving at all)

Expected results:
PDF should more or less print instantaneously.

Additional info:
As the PDF contains internal org charts, please let me know with whom i can share the PDF for testing.

Comment 3 Marek Kašík 2020-02-26 17:58:32 UTC
I'm moving this to RHEL 8. But I'm not sure whether this is fixable. Such files are big and needs a lot of CPU time to process. We render PDFs on cairo surfaces applying several transformations and then send them to printers. We don't send just the PDF and let printer or CUPS process the file (which is probably the case for Chrome and Firefox).
This would need several optimizations at different places in involved packages (mainly evince and poppler).
I've tested this on Cheyenne_100_P.pdf from https://aeronav.faa.gov/content/aeronav/sectional_files/PDFs/.

Comment 6 RHEL Program Management 2020-12-01 07:27:46 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.