Bug 661814

Can you print that jpg directly with 'lpr opgrat-email.jpg' ?

Can you attach an output from printing troubleshooter ?
https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter
When it asks you to print test page, print the .jpg either with lpr command (if that also causes the problem) or from firefox.

Created attachment 467854 [details]
debugging output

Printed correctly after 15-20 minutes.  Sending via lpr printed OK.

Under foomatic-db.noarch 0:4.0-23.20101123.fc14 jpg prints but takes an unacceptably long (~15 min) time. I'm not sure whether this might have been the case with the earlier version. I never waited that long.

(In reply to comment #2)
> Created attachment 467854 [details]
> debugging output
> 
> Printed correctly after 15-20 minutes.  Sending via lpr printed OK.

So this output is from printing via lpr ?
With foomatic-db-4.0-20.20100819.fc14 or foomatic-db-4.0-23.20101123.fc14 ?

Output is via lpr. With foomatic-db-4.0-23.20101123.fc14.

It's worse with foomatic-4.0.5-1.fc14.i686. Straight text works fine, but non-textual output (google map, for example) takes 20 min where previously it took a minute or so.

The driver installed for the HP LaserJet 1300 by default (presumably by the foomatic RPM is pxlmono. Turns out that's the wrong choice. Correct choice is Postscript

This issue will be fixed in system-config-printer-1.3.  The issue is that we can't be sure the printer supports PostScript unless we see that it says so in its IEEE 1284 Device ID.

Upstream report STR #3405 looks like it might be relevant to this:
  http://cups.org/str.php?L3405

I'll try changing the buffer size in the usb backend to 512 bytes instead of 8192 bytes.  Once I've built a package with that change I'll ask you to try it out using the pxlmono driver again.

Would be great if you could try this package:
  http://koji.fedoraproject.org/koji/buildinfo?buildID=213515

Download all the packages for your architecture and then run this command as root in the directory they are in:

yum update --nogpgcheck ./cups-*.x86_64.rpm

After doing this, please try printing using the pxlmono driver and see if the speed is any different.

*** Bug 670089 has been marked as a duplicate of this bug. ***

I was duplicated from BZ #670089, and I checked my problems after having updated to cups-1.4.6-2.fc14.i686.rpm and cups-libs-1.4.6-2.fc14.i686.rpm, I did reset my lexmark network printer to foomatic/pxlmono, then I tested to print http://www.rhrk.uni-kl.de, but, I'm sorry, nothing printed (behaviour as before installing then 2 rpm's). So my problem does not seem to be solved. Going back to foomatic/ljet4.

Printing that image through to a Foomatic/pxlmono PPD results in a 3.3Mb output file, compared to 0.6Mb for Foomatic/ljet4.

The reason the pxlmono driver is recommended for this printer is given in the foomatic-db ChangeLog:

2010-07-14  Till Kamppeter <till.kamppeter>

        * printer/HP-LaserJet_1200.xml, printer/HP-LaserJet_1220.xml,
          printer/HP-LaserJet_1300.xml, printer/HP-LaserJet_1320.xml,
          printer/HP-LaserJet_3390.xml, printer/HP-LaserJet_3392.xml:
          Recommend the "pxlmono" driver instead of HPLIP PostScript, these
          printers do not have enough memory for high-resolution PostScript
          printing.

Hmmmm ... this would seem to raise the question of how much memory. My experience with a standard-memory 1300 is that printing a relatively small JPG takes an unacceptable length of time, whereas with HPLIP it's virtually instantaneous. And that applies to a page with any graphics. As we're back to foomatic, I would suggest that  pxlmono needs to be evaluated _and_ the default driver returned to  HPLIP PostScript in the interim.

Reported upstream (printing-foomatic).

I've updated system-config-printer on the master branch so that it avoids pxlmono (it's hard to do this on the 1.2.x branch) in commit f4dad9b.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** Bug 675993 has been marked as a duplicate of this bug. ***

Exception removed upstream because the original problem causing large output file sizes for pxlmono was in ghostscript, and this bug is fixed in 9.04.  (See Launchpad #821818.)