From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 Description of problem: Selecting Print and "page 1 of 1" from Mozilla, and the following *consistently* occurs: The printer shoots out eight pages (unless it's switched off) before proceeding to print the _single_ page. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create printer using CUPS admin. 2.Open any web page in Mozilla, and select print page 1 of 1 (single page) 3.Do NOT turn off printer. Actual Results: Printer will feed eight blank sheets before proceeding to print the actual job. Expected Results: Printer should print on the very first sheet. Additional info: I have also deleted the printer via CUPS admin, and recreated it after a shutdown and restart of the system. Also, I have printed the page to a file,and the resulting "mozilla.ps" was easily readable in GGV. Changing the output configuration (image quality, dithering, etc, does NOT alter this behavoir. The printer ejects eight blank sheets before the actual job is printed. No such problem observed when printing from other applications (e.g. Abiword,Open Office, Image Magick, etc..) Hardware: Lexmark Z53 printer (parallel-port / USB model), connected via the usb port to an Atmel 4-port hub.
Sounds like something is screwed up on the printing side if it works OK in ggv.
My test page is the file:///usr/share/doc/HTML/index.html. When printed to file, and viewed via GGV, I notice that there *is* some corruption: to wit, the red and black background for ".... Step 1 activate your product..." does not display. Instead, there is a curved red line where the upper left and right corners should be. Likewise, at the bottom, except that the lines are black. In place of the red background, there is the default _white_ background, and the words "Step 1: Activate your product." Show as outlined white text (red outline). The section "Product activation ~ Click here to get started!" shows as _grey_ text, and the black background behind the "ACtivate" button is absent (shows white instead).
a couple of random tests printing to file: http://www.linuxmail.org/ and http://www.adabis.com/, show the problem to be consistent.
The thought occurred to me to print the mozilla.ps file from GGV. Sure enough, the printer shot out exactly *eight* blank sheets before proceding to print the actual job. Apparently this is not a Mozilla print problem, but a problem with postcript...
Freah, *clean* install of ((null)) --> rpm -q -a |grep cups qtcups-2.0-12 cups-drivers-1.9-1.20020617.6 cups-1.1.15-9 cups-drivers-hpijs-1.9-1.20020617.6 gimp-print-cups-4.2.1-5 cups-libs-1.1.15-9 cups-drivers-pnm2ppa-1.9-1.20020617.6 Lexmark Z53, Foomatic*Gimp-print ---> ejects 8 blank pages when printing from browser (Mozilla 1.0.1, Galeon 1.2.5), will NOT print from The Gimp. Lexmark Z53, Foomatic*Gimp-print-ijs ---> prints but will NOT print background graphics (e.g. any web page), *sends* from The Gimp, but will not print them, as the jobs bear a time-stamp that is 4 hours _ahead_ of the system clock!! Furthermore, the Gimp job cannot be "held" nor cancelled: " Error: client-error-forbidden" is the message received in the CUPS web admin. No problem printing from Image Magick... the problem is consistent between the browsers, and The Gimp.
It appears the printer was running out of black ink. How this could cause such wierd problems, I cannot fathom. At least, I can now print from a browser, _without_ the printer ejecting _exactly_ eight (8) blank pages, BEFORE actually printing the job. N.B. The printer is certainly NOT running out of coloured ink, so it still does not explain the following: However, I STILL cannot print from The Gimp. I see jobs being sent from The Gimp, but they CONSISTENTLY show up in the CUPS web admin page with a time stamp that is FOUR (4 hours) ahead of the system time. OTHER ERROR MESSAGES: 09 Sep. 2002 root]# /sbin/service lpd start Starting lpd: Fatal error - Cannot bind to lpd port '515' At each attempt, I would switch to LPD (if using LPRng only), or to CUPS, using the RH Printer System Switcher (red hat switch priter) utility. CURRENT VERSION LEVELS of software on the system (10 SEP. 2002): root]# rpm -q -a | grep cups qtcups-2.0-12 cups-drivers-1.9-1.20020617.6 cups-1.1.15-9 cups-drivers-hpijs-1.9-1.20020617.6 gimp-print-cups-4.2.1-5 cups-libs-1.1.15-9 cups-drivers-pnm2ppa-1.9-1.20020617.6
contents of /etc/printcap: ============================================================= # This file was automatically generated by cupsd(1m) from the # /etc/cups/printers.conf file. All changes to this file # will be lost. Lexmark: ============================================================= contents of /etc/printcap.old: ============================================================= # # DO NOT EDIT! MANUAL CHANGES WILL BE LOST! # This file is autogenerated by printconf-backend during lpd init. # # Hand edited changes can be put in /etc/printcap.local, and will be included. Lexmark:\ :ml#0:\ :mx#0:\ :sd=/var/spool/lpd/Lexmark:\ :af=/var/spool/lpd/Lexmark/Lexmark.acct:\ :sh:\ :lp=/dev/usb/lp0:\ :lpd_bounce=true:\ :if=/usr/share/printconf/util/mf_wrapper: ############################################################################### ## Everything below here is included verbatim from /etc/printcap.local ## ############################################################################### # printcap.local # # This file is included by printconf's generated printcap, # and can be used to specify custom hand edited printers. =============================================================
I guess I spoke too soon. Mozilla still causes the printer to eject exactly eight (8) blank pages before actually *printing*. It just happened moments before I write this, when I elected to print an email message (sent to me as plain ascii text, not HTML ... if that makes any difference...)
Success AT LAST! 1) The problem of the printer ejecting blanks appears to be ralated to the fact that it was _running low_ on black ink. 2) Though the printer is *physocally* attached via the usb port, printconf *insists* on defaulting to /dev/lp0, rather than /dev/usb/lp0 NOYE: The printer is correctoy identified as being connected as the first usb device in CUPS admin. 3) The Gimp: defaults to Postacript2 and printing to RAW rather than PS. Why?
> 1) The problem of the printer ejecting blanks appears to be ralated to the > fact that it was _running low_ on black ink. Weird. > 2) Though the printer is *physocally* attached via the usb port, printconf > *insists* on defaulting to /dev/lp0, rather than /dev/usb/lp0 > NOYE: The printer is correctoy identified as being connected as the first > usb device in CUPS admin. Okay, some printconf bug perhaps. > 3) The Gimp: defaults to Postacript2 and printing to RAW rather than PS. > Why? I think this is because the usual thing to want to do is raw printing with the specific type of printer specified, since that uses GIMP's high quality gimp-print driver for the conversion. This saves converting to PostScript for non-PS printers. But for PostScript it ought to modify its command-line not to use -oraw or something, or ask for confirmation, since that behaviour is clearly wrong.
printconf fixed in CVS. Changing component to gimp-print (msw: sorry, forgot that it's gimp-print not gimp here).
I also STILL have to remember to change the default in The Gimp to use -ops, instead of -oraw, which is always the default in Gimp.
Still present in Phoebe2 (RH 8.0.9.3)
Phoebe3 - RH 8.0.94 - default in The Gimp is still "lp -s -dLexmark -oraw"
Reported upstream.
https://sourceforge.net/tracker/index.php?func=detail&aid=700792&group_id=1537&atid=101537
This has been fixed upstream (5.0 CVS) by a redesign of the dialog.
*** Bug 132123 has been marked as a duplicate of this bug. ***
*** Bug 184180 has been marked as a duplicate of this bug. ***