[Printing-summit] [lsb-discuss] Printer/driver
uwehner at lanier.com
Mon Aug 21 11:27:24 PDT 2006
i have to agree with you (again)
there needs to be at least one method to configure printing that always
works. on a CUPS system this could\should be the CUPS web interface.
there can be any number of methods specific to OS\distro\desktop\user
preference to also do the job.
lpadmin has done a fairly universal job of configuring UNIX lpr....
SMIT has done it's job on AIX
SAM on HP-UX
Scoadmin on SCO,
I believe that not only technicians for printer manufacturers, but also
(and more importantly) system integrators would benefit greatly from a
universally available method of configuring the print system.
No reason for anybody to be overly difficult about this in CUPS land since
Mike is doing all the work any way.....
personally i have always liked kprinter, and (kudos to Tim Waugh) Redhat
now also has a usable printer configurator. Yast seems to work fine every
time i use it. Mandriva has always done a good job of providing
distro-specific tools that worked well...
(770) 493 2324
"Stark, Jens" <Jens.Stark at seeg.sharp-eu.com>
Sent by: printing-summit-bounces at lists.freestandards.org
"Johannes Meixner" <jsmeix at suse.de>
Steve Schafer <sschafer at synergy-tech.com>, Dan Kohn <dan at dankohn.com>,
"Wichmann, Mats D" <mats.d.wichmann at intel.com>, lsb-discuss
<lsb-discuss at lists.freestandards.org>,
printing-summit at lists.freestandards.org
Re: [Printing-summit] [lsb-discuss] Printer/driver testing
Johannes wrote (also shortened):
>> ... it should be one and the same for everybody.
>In the free software world this will never ever happen because
>if it happens somewhere for a longer time, this part can no longer
>belong to the free software world (otherwise it would have evolved).
>Instead of demanding "be one and the same for everybody"
>there must be reasonable specifications (e.g. LSB) so that
>something can be used the same way (but it must not "be the same").
Agreed. But would it be unreasonable to expect distributions not to break
the CUPS web interface ? For Willie the End User with his printer
connected via USB, the printer is the minor issue. He will be able to
setup his printer using the distro supplied maintenance/setup/config tool
(Which differ without a REAL need to. Same (worse) in the Unix world -
think of the likes of SMIT).
Enters the service person of a manufacturer of slightly bigger,
networkable printers/MFPs. This guy can usually repair hardware, knows
about networks, printing, scanning etc. on mostly Windows, maybe Mac. If
you are REALLY lucky, he can advise the local admin about issues like SAP
and mainframe printing, knows how to interact with accounting systems etc.
He might also know one Linux distro and a flavour of Unix or two. However,
his background is often hardware-based (a job requiring a lot of skill on
it's own.). He hasn't got time to work around 20 different versions of
printer setup, depending on distro flavour. If this guy could rely on the
CUPS web interface to work, without additional setup, without distro
specific changes, his job would be MUCH easier. And no, his time is far
too valuable to RTFM more than once - and it better be a good manual, too.
Of course, the CUPS interface will evolve over the years. But that is ONE
So my requirement would basically be : "Whatever tools are offered for
printer setup/maintenance in a system supporting CUPS, the CUPS web
interface and the CUPS command line interface must work out of the box and
provide full functionality.".
Let me add a second one: "In a system runbning CUPS, all printer
configuration and setup info must reside within CUPS."
For manufacturers, GNOME or KDE is not the question. (FVWM, anyone ?)
But for their support staff, it is critical to have ONE reliable
interface, especially if it already exists.
(And any time spent on distro wars should better be spent on making the
life of users easier.)
Printing-summit mailing list
Printing-summit at lists.freestandards.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Printing-summit