<br><font size=2 face="sans-serif">Paul,</font>
<br>
<br><font size=2 face="sans-serif">it appears that nobody wants to take
advantage of the work the largest printer setup training company (microsoft
:) has done.</font>
<br>
<br><font size=2 face="sans-serif">most people know how to set up a printer
under windows, i believe that we would do well if we did not make it more
difficult than that...</font>
<br>
<br><font size=2 face="sans-serif">looking forward to an intense discussion
in Atlanta at the summit</font>
<br>
<br><font size=2 face="sans-serif"><br>
Regards<br>
Uli Wehner<br>
Solutions Engineer<br>
(770) 493 2324</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Paul Tykodi"
<ptykodi@tykodi.com></b> </font>
<br><font size=1 face="sans-serif">Sent by: desktop_printing-bounces@lists.osdl.org</font>
<p><font size=1 face="sans-serif">03/30/2006 09:01</font>
<table DEFANGED_border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
ptykodi@tykodi.com</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif"><desktop_printing@lists.osdl.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: AW: [Desktop_printing] Role of CUPS
and error handling</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Dear Johannes,<br>
<br>
I believe that your current posting is an excellent prelude to the upcoming<br>
printing summit because for me it captures in a single posting what I<br>
believe is the single most important issue, which needs to be addressed
in<br>
the Linux printing space.<br>
<br>
That issue would be the tenet that Linux is first and foremost about choice.<br>
For me, I believe that currently the focus on openness and choice has<br>
greatly obscured the desire on the part of the majority of the Linux end<br>
user community to have a simple path for telling the OS (and by extension<br>
associated software components) that a printer is being defined to the<br>
system. <br>
<br>
As I have interpreted your posting, you are explaining in significant detail<br>
how SuSE has provided a series of independent component software products
to<br>
its community of users in support of their wish to define and use a printer.<br>
You also seem to be suggesting that SuSE has supporting documentation to<br>
show that in all cases SuSE has diligently followed the software provider's<br>
recommendations for installation steps whenever possible.<br>
<br>
The result in my opinion is that Linux printing currently mirrors our world<br>
quite well.<br>
<br>
Depending upon any individual person's level of user permission, Linux<br>
skill, printing hardware, backend selection (i.e. parallel, serial, USB,<br>
firewire, network, etc.), and printing related software selections the<br>
following is probably true:<br>
<br>
- YaST might work or it might not<br>
- CUPS configuration tools might work or they might not<br>
- Other spooler configuration tools might work or they might not<br>
- Linux system security settings might allow you to configure a printer
or <br>
they might not<br>
<br>
When Linux Printing support is then compared to the printing support in<br>
other prevalent desktop OS's (Apple & Microsoft OS Products) a major<br>
difference is typically noticed almost immediately by the end users I<br>
encounter. The other OS vendors have taken steps to improve the possibility<br>
an attempt to install a printer will most always succeed. The end users
I<br>
encounter typically suggest to me that they like having the printer setup<br>
odds skewed in their favor.<br>
<br>
My comments are specifically targeted at the process of getting the initial<br>
printer definition created under Linux correctly and not the follow on<br>
configuration of the driver and filters to provide the result needed by
any<br>
particular user (to me a much different issue).<br>
<br>
So for me the question regarding Linux printing and its acceptance by a
much<br>
broader cross section of users would be - Does the community of Linux<br>
Distribution providers and printing software component developers believe<br>
that skewing the printer installation process towards a high level of<br>
success would be good thing for their software and for Linux as a whole?<br>
<br>
HTH<br>
<br>
Best Regards,<br>
<br>
/Paul<br>
--<br>
Paul Tykodi<br>
Principal Consultant<br>
TCS - Tykodi Consulting Services LLC<br>
<br>
Tel/Fax: 603-343-1820<br>
Mobile: 603-866-0712<br>
E-mail: ptykodi@tykodi.com<br>
WWW: http://www.tykodi.com<br>
<br>
> Date: Thu, 30 Mar 2006 15:03:58 +0200 (CEST)<br>
> From: Johannes Meixner <jsmeix@suse.de><br>
> Subject: Re: AW: [Desktop_printing] Role of CUPS and error handling<br>
> To: desktop_printing@lists.osdl.org<br>
> Message-ID: <Pine.LNX.4.58.0603301239010.10962@wotan.suse.de><br>
> Content-Type: TEXT/PLAIN; charset=US-ASCII<br>
> <br>
> <br>
> Hello,<br>
> <br>
> On Mar 29 08:38 Robert L Krawitz wrote:<br>
> > From: Johannes Meixner <jsmeix@suse.de><br>
> > On Mar 27 10:09 Michael Sweet wrote (shortened):<br>
> > > The main issue is that, out of the box, SuSE's
web interface can't<br>
> > > work because there is no lppasswd set.<br>
> ><br>
> > Out of the box the cupsd must meet our general security
policy. We<br>
> > have a perfect dilemma: You demand your defaults
and we demand our<br>
> > general security policy but both contradict each
other.<br>
> ><br>
> > From the standpoint of doing technical support for Gutenprint,
I find<br>
> > that this raft of distribution-specific printer administration<br>
> > mechanisms causes no end of grief. I suspect that this
is a headache<br>
> > for any companies that want to distribute their own printer drivers,<br>
> > also.<br>
> ><br>
> > The usual scenario is "I'm trying to set up Gutenprint using
tool xxxx<br>
> > and it doesn't work quite right". We don't have the
resources to try<br>
> > to debug all of the vendor tools (and yes, it's not uncommon
that<br>
> > those tools at least contribute to the problem -- see my comment
the<br>
> > other day about seeing multiple identical PPD files, when they
should<br>
> > have been distinguished by language). At the same time,
I don't think<br>
> > that most distribution vendors want to do tech support for prerelease<br>
> > versions of Gutenprint, or for the Epson Kowa drivers, or what
have<br>
> > you.<br>
> ><br>
> > The upshot is that it's the end user who gets whipsawed here,
unable<br>
> > to get support from anybody, because it's an integration problem
that<br>
> > crosses organizational boundaries. That's not good for
any of us.<br>
> <br>
> When users test prerelease versions of Gutenprint they are<br>
> root on their system (i.e. no workstation user in a company<br>
> where the workstation was set up by an admin)<br>
> and they are not unexperienced users (because unexperienced users<br>
> should not try prerelease versions).<br>
> When those users fail to set up a queue because they don't know<br>
> how to use lpadmin or the CUPS web-frontend of the distibution<br>
> which they have installed on their computer, I have no idea<br>
> how to really help those users.<br>
> Don't think that I don't know such users. I started to work<br>
> at Suse in the support department and I have a nice collection<br>
> of several thousand answered support requests ;-)<br>
> <br>
> > Let me say that I have more than just a little sympathy for SUSE<br>
> > maintaining its security policy. Security's difficult enough
without<br>
> > trying to accommodate every quirk of every service. However,
I don't<br>
> > think it's helpful for vendors to say "CUPS as configured
out of the<br>
> > box doesn't meet our security needs, so we're just going to wash
our<br>
> > hands of the problem and write our own custom interface".<br>
> ><br>
> > There's a variety of possible solutions here, everything from
vendors<br>
> > (and KDE and GNOME, for that matter) agreeing to standardize
on a<br>
> > common interface to CUPS to the distribution vendors appointing<br>
> > liaisons to each project that will handle tech support issues
related<br>
> > to their distributions. But the current situation needs
to be fixed.<br>
> > The summit is an ideal place to start working on that.<br>
> <br>
> Regarding the whole posting:<br>
> <br>
> I am afraid but I do not understand well what you exactly mean.<br>
> <br>
> For me it looks as if you mix up printer config tool problems<br>
> and problems because of defaults in particular CUPS installations.<br>
> <br>
> <br>
> Regarding config tool:<br>
> <br>
> Our default printer config tool YaST existed before we switched<br>
> to CUPS as our default printing system.<br>
> <br>
> I assume you agree that we should not have simply dropped YaST<br>
> printer config and just forward the user to the CUPS web-interface.<br>
> <br>
> In particular not during the time when we supported both<br>
> LPRng/lpdfilter and CUPS.<br>
> We had even an automated migration from LPRng/lpdfilter to CUPS<br>
> and vice versa in YaST until Suse Linux 9.1<br>
> I hope you agree and understand that a smooth step by step move<br>
> from LPRng/lpdfilter to CUPS is better than leaving the user alone<br>
> how to switch his existing old config to a new printing system.<br>
> <br>
> Furthermore YaST can set up a queue for many local connected<br>
> printer models in a full-automated way:<br>
> When a model is autodetected, a matching PPD file is<br>
> searched and if found YaST set up a queue.<br>
> Many local connected printer models are set up full-automated.<br>
> I hope you agree and understand that this is more user-friendly<br>
> than what the CUPS web-interface (CUPS 1.1.x) can do.<br>
> <br>
> Finally YaST is translated into many languages.<br>
> Much more than the CUPS web-interface.<br>
> <br>
> Of course we kept YaST and did a smooth step by step move from a<br>
> LPRng/lpdfilter-only config tool via a LPRng/lpdfilter-and-CUPS<br>
> config tool to a CUPS-only config tool, for the history see<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.1_on<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.2_on<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.0_on<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.1_on<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.2_on<br>
> <br>
> What exactly do you mean with "common interface to CUPS"?<br>
> <br>
> YaST uses the CUPS API to set up queues.<br>
> <br>
> Since Suse Linux 9.1 YaST uses only PPDs to set up queues<br>
> (do not confuse YaST with the Red Hat tool), see<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.2_on<br>
> This means when you install any third-party software which<br>
> installs its PPDs into /usr/share/cups/model/ and which<br>
> installs its filters into /usr/lib[64]/cups/filter/<br>
> it should work out-of-the-box with YaST.<br>
> <br>
> If in the current YaST something is done regarding queue setup<br>
> which is not in full compliance how CUPS (1.1.x) is designed<br>
> to work, please tell me!<br>
> <br>
> It is a crucial feature since Suse Linux 9.1 that YaST and other<br>
> config tools (e.g. CUPS web front-end) are synchronized, see<br>
> http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.1_on<br>
> With "synchronized" I mean that you can use YaST and other<br>
> config tools in random order to add and/or change queues.<br>
> <br>
> I know that YaST does not really support same PPDs in different<br>
> languages (i.e. YaST ignores the LanguageVersion entry).<br>
> Usually it helps to toggel in YaST the manufacturer/model selection<br>
> to the plain PPD-file selection which lists the PPD files according<br>
> to the NickName entries but if the NickName is the same for PPDs<br>
> in different language, one cannot distinguish them.<br>
> <br>
> <br>
> Regarding defaults of a CUPS installation:<br>
> <br>
> We let cupsd run as non-root in compliance how CUPS (1.1.x)<br>
> is designed to work.<br>
> <br>
> If other config tools fail to work when CUPS runs in a<br>
> non-CUPS-default but CUPS-compliant mode, then there is a<br>
> problem in those other config tools.<br>
> I am not talking about the CUPS tools.<br>
> Both lpadmin and the web-frontend work perfectly as CUPS is<br>
> designed to work: lpadmin works out-of-the-box when it is run<br>
> as root on localhost and the CUPS web-frontend works perfectly<br>
> after root has set up a user to be CUPS admin (via "lppasswd").<br>
> <br>
> <br>
> Your posting sounds a bit as if you want to get rid of any other<br>
> printer config tool except the CUPS tools and as if you want<br>
> that it is forbidden to run CUPS in any non-CUPS-default mode.<br>
> >From other postings of you I assume that I am wrong because<br>
> I think that you like the freedom of choice.<br>
> <br>
> Please have in mind what I wrote in my previous posts:<br>
> -------------------------------------------------------------------<br>
> As far as I understand this discussion, it is about to agree<br>
> on a common standard but obviously any standard is ignored<br>
> when the common standard requires stuff which is not acceptable<br>
> by the policies or design guidelines or whatever guidelines<br>
> of the various parties (CUPS, the Linux distributors, KDE, Gnome).<br>
> -------------------------------------------------------------------<br>
> <br>
> <br>
> Kind Regards<br>
> Johannes Meixner<br>
> --<br>
> SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail:
jsmeix@suse.de<br>
> 90409 Nuernberg, Germany
WWW: http://www.suse.de/<br>
> <br>
<br>
_______________________________________________<br>
Desktop_printing mailing list<br>
Desktop_printing@lists.osdl.org<br>
https://lists.osdl.org/mailman/listinfo/desktop_printing<br>
</tt></font>
<br>