Closed Bug 429459 Opened 16 years ago Closed 15 years ago

Some (even simple) pages print very slow

Categories

(Core :: Printing: Output, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: u20230201, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080316 SUSE/1.1.9-1.1 SeaMonkey/1.1.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080316 SUSE/1.1.9-1.1 SeaMonkey/1.1.9

Some pages when being printed are very slow (as seen in the progress bar, and also on the printer). For example the page displayed when following the link named "Contact license delivery center" at https://webware.hp.com/welcome.asp: The page seen is a simple text page with a few colored background stripes. When printing to a PostScript printer (HP Laserjet 4250), the print file is 18429952 bytes.

Reproducible: Always

Steps to Reproduce:
1. Locate the page described above
2. Print it

Actual Results:  
It takes a lot of time until the print job is generated. It takes a lot of time until the print data is processed by the printer.

Expected Results:  
Faster printing, smaller print output, faster processing on the printer
Version: unspecified → SeaMonkey 1.1 Branch
Version being used in seamonkey-1.1.9-1.1 from openSUSE-10.3.
For the given page, this depends on whether or not you have "Print Background" checked in File > Page Setup. Without background, I'm ending up with 246628 bytes, no problem here, whereas with background 25355783 bytes are sent to the printer (also an HP Laserjet with CUPS 1.1.23 using SeaMonkey SUSE/1.1.9-1.1). Thus, it appears that a lot of redundant information is created for the background in this specific case.

The question is if there is some pattern that could be identified, meaning, for which "class(es)" of pages oversized PostScript or other delays are observed.
I'm unable to test this on SM 2.0 right now, but you should probably verify if the problem persists with the latest nightly "trunk" builds. Also, there is a recommendation in bug 427171 comment #6 to use a PS->PCL driver in CUPS, along with some other discussion on changes affecting printing under Linux.
Assignee: general → nobody
Component: General → Printing
Product: Mozilla Application Suite → Core
QA Contact: general → printing
Version: SeaMonkey 1.1 Branch → 1.8 Branch
Ulrich, sorry for getting back to you so late. I have upgraded a couple of components, running CUPS 1.3.7 now with the correct PPD files for my printer (was using Foomatic/PostScript before). I can reproduce this on openSUSE 11.0
with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.18) Gecko/20081110 SUSE/1.1.13-1.1 SeaMonkey/1.1.13 for one of the pages on that site, which is https://webware.hp.com/welcomepassword.asp (20572757 vs. 214826 bytes, that's with background vs. without). However, checking the current trunk version Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081201 SeaMonkey/2.0a2pre gives me just 108969 vs. 108375 for the same page.

Thus, it appears to me that this has been fixed and the problem should disappear when 2.0 is released. Unless you can reproduce it on trunk, I'd recommend to resolve this bug as "works for me".
That page does no longer exist for testing, but thus far I didn't see any
issues with the current Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4) Gecko/20091017 SUSE/2.0.0-3.1 SeaMonkey/2.0 release related to printing pages with gradients in the background. The printing backend changed substantially between 1.x and 2.0, thus closing WFM as suggested in comment #4.

Please feel free to reopen if this problem still exists, along with a link to a respective site for testing.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.