Hi Floid,
Thank you for submitting this bug and reporting a problem with
system-config-printer. You made this bug report in 2010 and Ubuntu has been
updated since then.
Could you confirm that this is no longer a problem and that we can close the
bug report?
If it is still a problem, are you still interested in finding a solution to
this bug?
If you are, could you let us know?
Thank you again for helping make Ubuntu better.
G
[Ubuntu Bug Squad volunteer triager]
** Changed in: system-config-printer (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to system-config-printer in Ubuntu.
https://bugs.launchpad.net/bugs/630410
Title:
Printer properties: Improve "Test Page" "Self Test Page" documentation
Status in system-config-printer package in Ubuntu:
Incomplete
Bug description:
Binary package hint: system-config-printer
Using system-config-printer 1.2.0 on Ubuntu 10.04LTS, I recently
discovered the true difference behind the "Print Test Page" and "Print
Self-Test Page" buttons in a printer's properties dialog. "Print Test
Page" appears to push the standard Ubuntu test page .ps through CUPS,
and functions as expected. At the present time, "Print Self-Test
Page" invokes print_self_test_page() in CUPS' filter/commandtops.c,
recognizable by the short bit of Postscript and "% You are using the
wrong driver" string spit out as plain text by the printer.
Of course, through the local CUPS httpd, "Maintenance->Print a Test
Page" prints the official *CUPS* test page (with palette circle and
CUPS logo), while "Maintenance->Print a Self Test Page" sends the same
Postscript directly to the non-Postscript printer.
---
Problems:
There is no "Help" available for the printer Properties dialog in
system-config-printer.
Currently the buttons and 'tooltips' available for test pages are:
Print Test Page:
"CUPS test page"
Print Self-Test Page:
"Typically shows whether all jets on a print head are functioning and that
the print feed mechanisms are working properly."
Clearly these descriptions are somewhere between "confusing" and "wrong." I
would suggest at least amending the buttons and tooltips as follows:
Print Test Page:
"Print a test page through CUPS as currently configured."
Print Self-Test Page:
"Send a Postscript script to generate a test page directly to the printer.
(For Postscript printers.)"
---
Now that I encounter these issues (and documentation issues) for the
umpteenth time, I am reminded that "we" need to do something about
terminology to stop pretending that we have monolithic "drivers"
(specifically, there's a tendency to try to pretend that the PPD 'is'
the driver, rather than that the PPD 'selects' the driver), and that
it's ever always going to work [because if it's not the vendor driver,
it's libusb, if it's not libusb, it's gs, if it's not gs, it's your
application, and if it's not your application, maybe everything's
working right but something's gone haywire with CUPS' state].
Note that Apple has essentially the *exact* same architecture with the
exact same problems; they just have the benefit of peripheral vendors
caring, and a somewhat slower release cycle (so once something works,
it doesn't get broken by a new patch until next year).
So if we have:
CUPS, providing a standard spooler framework;
The selected PPD, which:
- Defines the properties of the printer as it appears to 'Postscript'
applications;
- Defines the print filter (with RIP, if necessary)
Foomatic, playing the role of 'all-purpose swiss-army print filter
whether-you-need-a-RIP-or-not'
The RIP itself, in the form of the potentially fiddly vendor or open-source
'driver', generally relying on Ghostscript
The communications mechanism (also part and parcel of the 'driver')
... Is there a way we can communicate this to the user without making them
*wish* it was just a binary black box instead?
If "Help" were actually available (beyond *only* troubleshooting), the
article could at least make the point that "9 out of 10" of these functions are
incorporated haphazardly within each driver package for certain commercial
OSes, and the 'UNIX model' allows standardizing more of the commonly useful
features (fit-to-page, N-up), and 'minimizing' what can go wrong.
[Never mind that, by the time we get it all figured out, the price of
ink and relatively simpler software issues will have made tablets the
only way to go. ;)]
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/630410/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
