Hello, On Nov 21 19:03 Rajko M. wrote (shortened):

On Wednesday 21 November 2007 04:34:21 am Johannes Meixner wrote:

...

I hit this nail since several years now and what is the result? Probably it is the time for bigger hammer ;-)

Of course! Bigger hammer means more resources (in particular more manpower) but there is no more manpower (means more money) from Novell/Suse.

...

A usability expert who is really interested in printing is needed. I mean someone who is willing to learn the real printing model so that we could add real value and not only "yet another setup tool user interface beautification" ( YaST -> YaSTUIB ;-)

You as printing expert can help a lot, by creating some schematics to present smaller blocks of a black box, so that guys that have interest can ask questions.

Currently I can provide only this text-based description http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Some links to CUPS 1.1 pages are outdated for CUPS 1.2 which we have since openSUSE 10.2 - I need to update it - if time permits... Regarding diagrams: If time permits I could create some and add them to http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Additionally I could mention what can be considered to be a "driver": Strictly speaking (i.e for experts) the driver is the one single program in the CUPS filter chain which is actually responsible to produce printer specific data. For an usual user the "driver" can be considered to be the whole CUPS filtering system together with the printer specific PPD file. But it is plain wrong if a user thinks the PPD file is the driver. For "CUPS Filter System Background Information" see http://en.opensuse.org/SDB:Using_Your_Own_Filters_to_Print_with_CUPS I append a mail with some details regarding print queue setup. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex #################################################################### Date: Tue, 13 Mar 2007 12:55:45 +0100 (CET) From: Johannes Meixner To: ... Hello, a long mail with background information from the bottom-up point of view (i.e. from the point of view of the printing system). On Mar 1 17:39 Martin Schmidkunz wrote (shortened):

we are planning to conduct a usability test where we compare various printer modules

To avoid misunderstandings and communication problems, I try to describe very pedantic what I mean. Please don't be upset because of this. I want to be 100% safe that there are no misunderstandings because in the past it happened so often that discussions get lost in a mess of non-exact words like the ancient http://en.wikipedia.org/wiki/Confusion_of_tongues First of all I define what I mean with the following terms: "printer" means the hardware which actually prints "queue" means the representation of a printer in a computer "filter" means the set of programs which produce printer-specific data (the filter includes the printer-specific printer driver) "driver" means the one particular program in the set of filter programs which is actaully printer-specific (i.e. each kind of printer requires its matching driver) "person" means a human who works with the computer "user" means any representation of a person in a computer and usually it means only an unprivileged user "normal user" means explicitely an unprivileged user - i.e. when the person does not know an admin or root password "root" means the user with unlimited privileges - i.e. when the person knows the root password "admin" means a special privileged user - e.g. a user who can set up queues "local printer" means a printer which is directly connected to the computer where the person sits in front of "remote printer" means a printer which is not directly connected to the computer where the person sits in front of "network printer" means a printer which is directly connected to the network (and not to another computer in the network) "local queue" means a queue which exists directly on the computer where the person sits in front of "remote queue" means a queue which exists on whatever computer in the network or on whatever network printer A) The very basics about setting up a local printer: Setting up a local printer means to create a local queue. Creating a (usual) local queue requires three mandatory parameters (there is the special case of a "raw" queue which doesn't need 2. see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "The Filter"): 1. One parameter describes how the printer is connected (i.e. how the printing system can send data to the printer). This parameter is the so called "DeviceURI". For background information see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "The Backends" 2. One parameter describes which driver is to be used (i.e. how the printing system can produce printer-specific data). This parameter is the so called "PPD file". For background information see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "PPD Files" 3. One parameter is a name for the queue If this three parameters are known, a queue is created via root@host# lpadmin -p queue-name -v DeviceURI -P PPD-file-name -E For background information see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Command-line Tools" All what a printer setup tool must do is to determine this three parameters and then call "lpadmin". B) The very basics about setting up printing in the network: There are no very basics about setting up printing in the network. It is inherently complicated. The reason is that there are various possibilities which depend on what there was actually set up "out there" in the particular network of the particular computer where the particular person sits in front of. Some examples: a) If there exists a remote queue for the remote printer, should only access to the remote queue be set up or should a local queue be created for the remote printer? b) If there exists no remote queue for the remote printer, a local queue must be created for the remote printer. How is the remote printer accessible? If it is a network printer, is it accessible via plain TCP socket or via LPD protocol or via IPP protocol? If the remote printer is connected to a remote computer, how is the remote printer accessible? Usually (because of A) there is a queue on the remote computer to which the remote printer is connected to so that we are back at case a). c) If only access to a remote queue should be set up: Does the remote queue do filtering or not? If not, a local queue with filtering must be created. If yes, is the remote queue broadcasted by a remote CUPS server? If no, a local queue must be created. If yes, are there whatever other local queues? If no, a CUPS "client-only" setup should be perfect, see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Client-only configuration". and so on and so on ... Currently I have no idea how to set up printing in the network in a simple and easy-to-understand way for unexperienced users. Currently YaST does some best-guess. I hope that a thorough analysis can show that either best-guess is all what can be done or a easy-to-understand way is found. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex #################################################################### -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org