Bug 86376
| Summary: | Defective CUPS drivers | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | G.S. Link <gslink> |
| Component: | cups | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-01-07 12:56:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
By 'supplied drivers', do you mean something other than what is provided by Red Hat Linux? Please describe what you are doing in terms of which applications you run to configure the queue, what options you select, etc. If you switch your printer support in a STANDARD installation as supplied by Red Hat with no additional software to CUPS you will need to define printers with the CUPS setup program. This is what I did. The above problem appears on ANY software even the CUPS printer test sheet. The driver for a plain Laserjet, while it works with the 4450, produces a test sheet with the border frame cut off on either the top or bottom or both but it is usable. In addition, another problem appears with the Postscript driver. On many of the newer printers such as The Lexmark E312 the CUPS test sheet image appears slightly larger than it should be. When an image from a supplied application such as Open Office or Kword is printed the image extends beyond the printable area. Sending the printer a non-Postscript image corrects the problem. It appears to me that the paper dimension returned is in some way incorrect. All of these tests were done with U.S. Letter size. We finally looked at the coordinates that the current Java 1.4 jre returns. These proved to be different for the same paper size depending on what driver was used. This was true even for the same printer and paper. The Postscript driver puts 0,0 to the left of the printable area but a non-Postscript driver does not. I do not know how much Red Hat was involved in CUPS but I suspect these defects came from the CUPS supplier as the problem was inherited from 8.0 and earlier. > If you switch your printer support in a STANDARD installation as supplied by Red
> Hat with no additional software to CUPS you will need to define printers with
> the CUPS setup program. This is what I did.
No, this isn't true: redhat-config-printer sets up CUPS on your behalf.
The page dimension differences you mention sound like the 'imageable area',
which does indeed come from the driver. But this is correct, since only
full-bleed-capable printers can print right to the edge of the page.
Please let's concentrate on one particular bug, so that this report can be
tracked more easily: the original 4450 problem you mentioned. Please attach the
output of 'printconf-tui --Xexport' after you have set up a print queue for it
using redhat-config-printer and seen the 'garbage' output.
Further testing revealed that the bug actually consists of two things. Checking Postscript 1 or 2 in the Cups setup for a printer should cause level 1 or 2 Postscript to be produced. It does not. The Postscript that comes out is not recognized by older printers which require level 1 or 2. I have not looked at the actual Postscript but both the Panasonic 4455 and Lexmark 4039 discard all Postscript from Linux regardless of level setting. They see it as garbage for some reason. Neither handles Postscript level 3. An Optra S prints properly. The other thing is that some things in Linux dump blank pages. Most later printers suppress blanks. Earlier printers do not. This produces quantities of garbage in the form of blank pages and near blank pages. I no longer have access to the 4455 and thus cannot perform further tests but I believe this post to be the actual bug. As time permits I will look at the Postscript output sent to the 4039 and attempt to find the problem but I believe that no older Postscript printer will work with Cups. I have not tried any other printing method. It may well be that what actually comes from Linux when Pcl5 is required is Pcl6 but if that is true it should be the subject of another bug report. Let us confine this report to the Postscript garbage problem. Whatever you call it, click the red hat and then extras. Click system tools and then Cups Printer configuration. I suppose you could setup Cups manually but why bother. The only thing I know of that this Cups configuration won't do is kill a print job. That has to be done from a console. The tool you should use is accessible in this manner: Red Hat menu -> System Settings -> Printing Is that what you are using? Please supply the output of 'printconf-tui --Xexport' when you've set the queue up with that tool and set the 'Ghostscript pre-filtering' option to 'Convert to PS level 1' and still see the problem. Thanks. Closing, no feedback. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: The problem first appeared on a Panasonic 4455. When running in 4450 mode the supplied 4450 setup provides a driver stack that compresses the test image to about 2 inches on the left side of the page. Other drivers were tested and this is true of any driver from a Lazerjet 2P on. The problem was observed on other early printers also. When the 4455 is run in Postscript mode that also fails as the version of PS in every driver is later than the printer will handle. Even though setup is listed for many early printers they appear not to be supported. In order to use them you must use the setup for plain Laserjet. This gives incorrect image sizes and causes things to be cut off. Most early Postscript printers seem to fail in Postscript mode but will run in non Postscript mode and are more or less supported. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Configure a 4455 or 4450 with the supplied drivers 2.Print test page 3. Actual Results: Garbage in 4450 mode File ignored in Postscript mode Expected Results: Printer should have worked Additional info: This bug probably affects many older printers but we didn't have enough older printers to really be able to tell the true extent of the problem.