<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>&quot;Paul Tykodi&quot;
&lt;ptykodi@tykodi.com&gt;</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">&lt;desktop_printing@lists.osdl.org&gt;</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>
 &nbsp;they might not<br>
<br>
When Linux Printing support is then compared to the printing support in<br>
other prevalent desktop OS's (Apple &amp; 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: &nbsp;603-866-0712<br>
E-mail: &nbsp;ptykodi@tykodi.com<br>
WWW: &nbsp; &nbsp; http://www.tykodi.com<br>
<br>
&gt; Date: Thu, 30 Mar 2006 15:03:58 +0200 (CEST)<br>
&gt; From: Johannes Meixner &lt;jsmeix@suse.de&gt;<br>
&gt; Subject: Re: AW: [Desktop_printing] Role of CUPS and error handling<br>
&gt; To: desktop_printing@lists.osdl.org<br>
&gt; Message-ID: &lt;Pine.LNX.4.58.0603301239010.10962@wotan.suse.de&gt;<br>
&gt; Content-Type: TEXT/PLAIN; charset=US-ASCII<br>
&gt; <br>
&gt; <br>
&gt; Hello,<br>
&gt; <br>
&gt; On Mar 29 08:38 Robert L Krawitz wrote:<br>
&gt; &gt; &nbsp; &nbsp;From: Johannes Meixner &lt;jsmeix@suse.de&gt;<br>
&gt; &gt; &nbsp; &nbsp;On Mar 27 10:09 Michael Sweet wrote (shortened):<br>
&gt; &gt; &nbsp; &nbsp;&gt; The main issue is that, out of the box, SuSE's
web interface can't<br>
&gt; &gt; &nbsp; &nbsp;&gt; work because there is no lppasswd set.<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;Out of the box the cupsd must meet our general security
policy. &nbsp;We<br>
&gt; &gt; &nbsp; &nbsp;have a perfect dilemma: You demand your defaults
and we demand our<br>
&gt; &gt; &nbsp; &nbsp;general security policy but both contradict each
other.<br>
&gt; &gt;<br>
&gt; &gt; From the standpoint of doing technical support for Gutenprint,
I find<br>
&gt; &gt; that this raft of distribution-specific printer administration<br>
&gt; &gt; mechanisms causes no end of grief. &nbsp;I suspect that this
is a headache<br>
&gt; &gt; for any companies that want to distribute their own printer drivers,<br>
&gt; &gt; also.<br>
&gt; &gt;<br>
&gt; &gt; The usual scenario is &quot;I'm trying to set up Gutenprint using
tool xxxx<br>
&gt; &gt; and it doesn't work quite right&quot;. &nbsp;We don't have the
resources to try<br>
&gt; &gt; to debug all of the vendor tools (and yes, it's not uncommon
that<br>
&gt; &gt; those tools at least contribute to the problem -- see my comment
the<br>
&gt; &gt; other day about seeing multiple identical PPD files, when they
should<br>
&gt; &gt; have been distinguished by language). &nbsp;At the same time,
I don't think<br>
&gt; &gt; that most distribution vendors want to do tech support for prerelease<br>
&gt; &gt; versions of Gutenprint, or for the Epson Kowa drivers, or what
have<br>
&gt; &gt; you.<br>
&gt; &gt;<br>
&gt; &gt; The upshot is that it's the end user who gets whipsawed here,
unable<br>
&gt; &gt; to get support from anybody, because it's an integration problem
that<br>
&gt; &gt; crosses organizational boundaries. &nbsp;That's not good for
any of us.<br>
&gt; <br>
&gt; When users test prerelease versions of Gutenprint they are<br>
&gt; root on their system (i.e. no workstation user in a company<br>
&gt; where the workstation was set up by an admin)<br>
&gt; and they are not unexperienced users (because unexperienced users<br>
&gt; should not try prerelease versions).<br>
&gt; When those users fail to set up a queue because they don't know<br>
&gt; how to use lpadmin or the CUPS web-frontend of the distibution<br>
&gt; which they have installed on their computer, I have no idea<br>
&gt; how to really help those users.<br>
&gt; Don't think that I don't know such users. I started to work<br>
&gt; at Suse in the support department and I have a nice collection<br>
&gt; of several thousand answered support requests ;-)<br>
&gt; <br>
&gt; &gt; Let me say that I have more than just a little sympathy for SUSE<br>
&gt; &gt; maintaining its security policy. &nbsp;Security's difficult enough
without<br>
&gt; &gt; trying to accommodate every quirk of every service. &nbsp;However,
I don't<br>
&gt; &gt; think it's helpful for vendors to say &quot;CUPS as configured
out of the<br>
&gt; &gt; box doesn't meet our security needs, so we're just going to wash
our<br>
&gt; &gt; hands of the problem and write our own custom interface&quot;.<br>
&gt; &gt;<br>
&gt; &gt; There's a variety of possible solutions here, everything from
vendors<br>
&gt; &gt; (and KDE and GNOME, for that matter) agreeing to standardize
on a<br>
&gt; &gt; common interface to CUPS to the distribution vendors appointing<br>
&gt; &gt; liaisons to each project that will handle tech support issues
related<br>
&gt; &gt; to their distributions. &nbsp;But the current situation needs
to be fixed.<br>
&gt; &gt; The summit is an ideal place to start working on that.<br>
&gt; <br>
&gt; Regarding the whole posting:<br>
&gt; <br>
&gt; I am afraid but I do not understand well what you exactly mean.<br>
&gt; <br>
&gt; For me it looks as if you mix up printer config tool problems<br>
&gt; and problems because of defaults in particular CUPS installations.<br>
&gt; <br>
&gt; <br>
&gt; Regarding config tool:<br>
&gt; <br>
&gt; Our default printer config tool YaST existed before we switched<br>
&gt; to CUPS as our default printing system.<br>
&gt; <br>
&gt; I assume you agree that we should not have simply dropped YaST<br>
&gt; printer config and just forward the user to the CUPS web-interface.<br>
&gt; <br>
&gt; In particular not during the time when we supported both<br>
&gt; LPRng/lpdfilter and CUPS.<br>
&gt; We had even an automated migration from LPRng/lpdfilter to CUPS<br>
&gt; and vice versa in YaST until Suse Linux 9.1<br>
&gt; I hope you agree and understand that a smooth step by step move<br>
&gt; from LPRng/lpdfilter to CUPS is better than leaving the user alone<br>
&gt; how to switch his existing old config to a new printing system.<br>
&gt; <br>
&gt; Furthermore YaST can set up a queue for many local connected<br>
&gt; printer models in a full-automated way:<br>
&gt; When a model is autodetected, a matching PPD file is<br>
&gt; searched and if found YaST set up a queue.<br>
&gt; Many local connected printer models are set up full-automated.<br>
&gt; I hope you agree and understand that this is more user-friendly<br>
&gt; than what the CUPS web-interface (CUPS 1.1.x) can do.<br>
&gt; <br>
&gt; Finally YaST is translated into many languages.<br>
&gt; Much more than the CUPS web-interface.<br>
&gt; <br>
&gt; Of course we kept YaST and did a smooth step by step move from a<br>
&gt; LPRng/lpdfilter-only config tool via a LPRng/lpdfilter-and-CUPS<br>
&gt; config tool to a CUPS-only config tool, for the history see<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.1_on<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.2_on<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.0_on<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.1_on<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.2_on<br>
&gt; <br>
&gt; What exactly do you mean with &quot;common interface to CUPS&quot;?<br>
&gt; <br>
&gt; YaST uses the CUPS API to set up queues.<br>
&gt; <br>
&gt; Since Suse Linux 9.1 YaST uses only PPDs to set up queues<br>
&gt; (do not confuse YaST with the Red Hat tool), see<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.2_on<br>
&gt; This means when you install any third-party software which<br>
&gt; installs its PPDs into /usr/share/cups/model/ and which<br>
&gt; installs its filters into /usr/lib[64]/cups/filter/<br>
&gt; it should work out-of-the-box with YaST.<br>
&gt; <br>
&gt; If in the current YaST something is done regarding queue setup<br>
&gt; which is not in full compliance how CUPS (1.1.x) is designed<br>
&gt; to work, please tell me!<br>
&gt; <br>
&gt; It is a crucial feature since Suse Linux 9.1 that YaST and other<br>
&gt; config tools (e.g. CUPS web front-end) are synchronized, see<br>
&gt; http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.1_on<br>
&gt; With &quot;synchronized&quot; I mean that you can use YaST and other<br>
&gt; config tools in random order to add and/or change queues.<br>
&gt; <br>
&gt; I know that YaST does not really support same PPDs in different<br>
&gt; languages (i.e. YaST ignores the LanguageVersion entry).<br>
&gt; Usually it helps to toggel in YaST the manufacturer/model selection<br>
&gt; to the plain PPD-file selection which lists the PPD files according<br>
&gt; to the NickName entries but if the NickName is the same for PPDs<br>
&gt; in different language, one cannot distinguish them.<br>
&gt; <br>
&gt; <br>
&gt; Regarding defaults of a CUPS installation:<br>
&gt; <br>
&gt; We let cupsd run as non-root in compliance how CUPS (1.1.x)<br>
&gt; is designed to work.<br>
&gt; <br>
&gt; If other config tools fail to work when CUPS runs in a<br>
&gt; non-CUPS-default but CUPS-compliant mode, then there is a<br>
&gt; problem in those other config tools.<br>
&gt; I am not talking about the CUPS tools.<br>
&gt; Both lpadmin and the web-frontend work perfectly as CUPS is<br>
&gt; designed to work: lpadmin works out-of-the-box when it is run<br>
&gt; as root on localhost and the CUPS web-frontend works perfectly<br>
&gt; after root has set up a user to be CUPS admin (via &quot;lppasswd&quot;).<br>
&gt; <br>
&gt; <br>
&gt; Your posting sounds a bit as if you want to get rid of any other<br>
&gt; printer config tool except the CUPS tools and as if you want<br>
&gt; that it is forbidden to run CUPS in any non-CUPS-default mode.<br>
&gt; &gt;From other postings of you I assume that I am wrong because<br>
&gt; I think that you like the freedom of choice.<br>
&gt; <br>
&gt; Please have in mind what I wrote in my previous posts:<br>
&gt; -------------------------------------------------------------------<br>
&gt; As far as I understand this discussion, it is about to agree<br>
&gt; on a common standard but obviously any standard is ignored<br>
&gt; when the common standard requires stuff which is not acceptable<br>
&gt; by the policies or design guidelines or whatever guidelines<br>
&gt; of the various parties (CUPS, the Linux distributors, KDE, Gnome).<br>
&gt; -------------------------------------------------------------------<br>
&gt; <br>
&gt; <br>
&gt; Kind Regards<br>
&gt; Johannes Meixner<br>
&gt; --<br>
&gt; SUSE LINUX Products GmbH, Maxfeldstrasse 5 &nbsp; &nbsp; &nbsp;Mail:
jsmeix@suse.de<br>
&gt; 90409 Nuernberg, Germany &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;WWW: http://www.suse.de/<br>
&gt; <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>