Bug 168485

*** Bug 133630 has been marked as a duplicate of this bug. ***

*** Bug 174053 has been marked as a duplicate of this bug. ***

Here is my overview of printing on the desktop.  I will be drilling down further
this week expecially on the system-config-printer portion.

Problems with Linux's Printing Architecture on the Desktop

Major Themes:

* We are about %50 there 
  - a huge portion of the existing work is mostly political and not technical 

* Need for buy-in from OEMs to work with the foomatics and driver people

* Printer model numbers mean nothing to a user and neither do drivers

* Foomatics is slooowwww and inconsistent

* CUPS needs to be more desktop friendly 
  - Better access controls and functionality than what is provided via IPP
  
* Deriving GUI's from PPD files is not ideal


We are about %50 done

What we have is a full stack of separate tools that need to be glued together by
distributions.  Currently this is mostly done via a root level configuration
tool which uses these tools to construct a printer queue with a lot of user
interaction.

List of current stack elements:

* CUPS - provider of printer backends, printer discovery and a print scheduler

* FOOMATICS - database which contains printer configuration information based on
make and model

* distro specific configuration backend - used to create, delete and edit
printer queues

* client libraries - used to format data so it can be printed via cups

List of extra stack elements in Fedora's desktop printing arch:

* HAL - used for local printer discovery and automatic queue configuration 

* D-Bus - used as a transport to gather state information from CUPS (via a
patch) and signal applications when printers are configured or need extra
configuration 

* hal cups backend - a cups backend that uses HAL udi's instead of devices for
accessing printers

* eggcups - a printer notification tray icon that keeps track of current print
jobs and allow you to cancel a job, it also listens for configuration requests
and pops up a dialog requesting the make and model of a printer if it can not
automatically configured.

What is needed is accepted interfaces for gluing all these pieces together.  In
a perfect world CUPS and distro specific configuration tools would export a
simple and common interface for querying and configuring printers from the
desktop.  While IPP does give us some of this for desktop purposes it is not
nearly enough.  More on IPP and interfaces bellow.

Most of the work is deciding on the architecture which is why I stated above
that it is mostly a political hurdle (we have one in Fedora but will people
accept it?).  The work also involves trying to somehow involve printer
manufactures on a whole new level.


Need for buy-in from OEMs to work with the foomatics and driver people

This is important.  Right now with my Canon PIXMA iP90 there is no foomatics
entry (at least with the version I have on my workstation) but with some intense
googling I was able to find a make and model that allowed me to print (I can't
remember which it was now).  I understand that manufactures don't want to
endorse drivers that don't work 100% with their equipment but having an active
dialog with the foomatics people such as letting them know when new models are
coming out and what other models they are most similar to would be great.  Even
better is providing information that would help driver developers write drivers
for the new models.  The best however would be for the manufactures to write an
acceptably licensed driver themselves.

Whether or not this can be solved is a sticking point but the companies who
would jump on the band wagon are certain to get a lot of PR points.


Printer model numbers mean nothing to a user and neither do drivers

Desktop users just want their printers to work for the most part.  Having to
select drivers or makes and models just doesn't work.  As noted above, I had a
hard time finding a make and model that was similar to my Pixma and I can't even
remember what it was once I found it out.  Pretty much the only fix for this is
working closer with OEMs so uses won't have to pick.  But how do we make it
easier for them to pick if they have to?  That is an open question.  Part of the
problem is the cryptic names of models.  If the Pixma was to show up in
foomatics would it be listed as PIXMA iP90 or just iP90?

Foomatics is slooowwww and inconsistent

Querying the database of XML files on some older machines (using make and model
as indicies) can clearly take minutes of harddrive thrashing. Even on my modern
dual Xeon system the results are not instantaneous.  We need to come up with a
format that is optimized for querying on make and model as this is the
information we get from the printer itself.  Also foomatics does not always
match up with the exact IEEE naming scheme that printers give back.  The biggest
offenders I have seen are with HP printer entries.  Sometimes they are listed as
HP, sometimes Hewlett-Packard and sometimes HEWLETT-PACKARD.  All naming schemes
should match exactly what the printer gives back when queried.  If different
model printers give back different strings we need to make sure one canonical
name is picked and used for the purpose of displaying to the user.

CUPS needs to be more desktop friendly

Programming over IPP is not easy and doesn't always fit in with the desktop
application model of development.  While I would not propose replacing it,
complimenting it with D-Bus for the desktop oriented features would be a huge
improvement making it easier to integrate on the desktop side.  This is because
D-Bus can supply desktop oriented ACL authentication (for example restricting
commands to those who are logged in at the console i.e. physically at the
computer).  It is also has bindings for major toolkits such as GLib2 and Qt4
(and a first pass binding for Qt3).  Functionality needed would be adding,
removing and renaming queues, canceling jobs, getting status information on jobs
and sending signals for job notifications.  Much of this can be hooked up to the
existing code and just act as an interface.

As it is right now in Fedora and RHEL we have a patch that polls CUPS and
signals job status and printer addition and removal events.  While D-Bus doesn't
fix all the problems we have with CUPS it does make it easier for desktops to
integrate.

CUPS itself needs better and more timely feedback of pertinent user information
no matter what transport is used.  There is a IPP notification spec already but
when will we see it in actual use?  What is simply needed is a simple feedback
mechanism with querying capabilities.  After having that we would be able to
write apps to do whatever is needed with the information at hand.


Deriving GUI's from PPD files is not ideal

Right now we don't always supply options that are listed in the PPD file (i.e.
legal vs. letter page size).  PPD files have an intent to be used to generate
GUIs but generating GUIs from the description produces sub par results.  Clients
libraries need to find a balance between the generating a GUI and showing a
simple yet functional dialog of options.  One suggestions is the apple approach
where they have tabs of options and the last tab is all the options in a tree
view format for advanced users. 

> Also foomatics does not always
> match up with the exact IEEE naming scheme that printers give back.  The 
> biggest offenders I have seen are with HP printer entries.  Sometimes they
> are listed as HP, sometimes Hewlett-Packard and sometimes HEWLETT-PACKARD.
> All naming schemes should match exactly what the printer gives back when 
> queried.  If different model printers give back different strings we need
> to make sure one canonical name is picked and used for the purpose of 
> displaying to the user.

Just to comment on this: different HP printer models give back different
strings, sometimes 'hp', sometimes 'Hewlett-Packard' -- this is beyond our
control, and we just need to have our IEEE 1284 strings in foomatic match
whatever the printer gives.  Occasionally there are mistakes, but I am
correcting them whenever someone reports them.

For the purpose of displaying to the user, the IEEE 1284 strings are completely
irrelevant.  The XML <make> and <model> tags are used for this, quite
independently of what the IEEE 1284 string says (if there even is one).

We could certainly do with having IEEE 1284 strings listed for more printer
models!  This is really more of an upstream foomatic issue though, rather than
something to take into account for a redesign of our config tool.

> Deriving GUI's from PPD files is not ideal

FWIW, foomatic is moving away from having options expressed in the XML, and
instead is providing PPDs which we must parse. :-(

I just like to add my current experience with system-config-printer while trying
to setup a wireless HP printer (model 5850) in fc4.

I found out through a user comment on linuxprinting.org that the printer can be
setup by using JetDirect as "Queue type" and typing the IP of the printer. After
doing that and clicking on "OK" I thought "yep, this is saved, lets see if it
works". No, of course it didn't. 
In short, it took me several time to figure out that the "Apply" (in German
"Ãbernehmen") button in the main window was needed to actually save the changes
I made. I know that this is noted in the docs - I found that out later on after
clicking on "Help". I think I haven't used this button earlier since I was
thinking either "I need to get this thing going without looking in the online
help", "I don't need to click on Help, it will be probably outdated as most
linux UI documentation anyways" or something along the line.
In the end the documentation would have helped me (because I can understand
english), but no one else who isn't fluent in this language. Have I noted that
parts of the printer dialog are translated, others not?

Anyways, it also took me a while to notice that I don't need to enter
socket://<ipaddress> but only <ipaddress> in the "Printer:" field - actually I
found that out by using $ lpstat -t (stumbled across this one on Google as well).

Back to the main dialog. In comparison to system-config-network, which has a
"Datei -> Speichern" (in english probably "File -> Save") menu entry to save the
entered settings I found the above way pretty unintuitive named "Aktion ->
Ãbernehmen" (I'm not sure about the original english strings). I'm also not sure
about other system-config-* modules, but I believe they differ in these things
as well.

It would be a good start after the internal changes in this module to redesign
the UI as well. The printer dialog is feature-overloaded and might need some
changes as well (or an option "switch to advanced mode").

In the end I learned something about CUPS, linux printing and all, but it made
me quite sad to see that I needed 10 mins to setup this printer on an iBook with
MacOS X 10.4 installed (where there was an auto-search for network printers in
the current network... how cool and neat!) and more than one hour on Linux. Ok,
call me a noob, a stupid user, whatever, but until the community is still that
feature-oriented when it comes to UI design, we will continue having a hard time
to see Linux actually arriving on Joe Users desktop in the near future.

My 2ct,
Tommy.

*** Bug 187016 has been marked as a duplicate of this bug. ***

This is clearly in-progress with the system-config-printer 0.7.x package that
just went into rawhide. A few comments on the new package:

Packaging:
- missing the "Obsoletes: system-config-printer". Probably everyone has noticed
  that by now.
- although this is version 0.7.x of a package that was previously 0.6.x,
  changelog _starts_ with "Wed Mar 15 2006 [...] Initial spec file."
  Even if the specfile was redone from scratch, at least some of the old 
  changelog should be carried over to avoid confusing, um, me. And other 
  people. :)


The package itself:
- missing a text-mode GUI
- missing command-line options

Thanks for the feedback.

> - missing the "Obsoletes: system-config-printer".

Fixed in 0.7.4-2.

> [changelog]

This was a complete re-write, including the spec-file.  The only remaining code
from the previous package is a few lines of pycups.  The new changelog reflects
that.

> - missing a text-mode GUI

These will not be a text-mode GUI.  Instead, there is the possibility of
configuring a remote X-less CUPS server.  See the design document I posted to
fedora-devel-list.

Or, alternatively, you can use the http://localhost:631/ GUI using your
favourite text-mode browser.

> - missing command-line options

Not true.  Whereas before the only command-line tool you could use was
printconf-tui, now you get to use lpadmin/lpoptions/etc.

(NB: please file future bugs/requests/observations as new bugzilla bugs against
Fedora Core devel.)

>> - missing the "Obsoletes: system-config-printer".

Um, that should have been "system-config-printer-gui" -- hope you caught that.


> These will not be a text-mode GUI. 

Okay. It should at least exit gracefully when DISPLAY isn't set.

Pointing a text-mode web browser at http://localhost:631/ isn't a great option,
but I can see that as an upstream problem.

>> - missing command-line options
> Not true.  Whereas before the only command-line tool you could use was
> printconf-tui, now you get to use lpadmin/lpoptions/etc.

Nonetheless, 'system-config-printer --help' ought to work at the very least.


> (NB: please file future bugs/requests/observations as new bugzilla bugs
> against Fedora Core devel.)

I will. Sorry for being lazy. :) Would you like me to file bugs for the 

(In reply to comment #9)
> > These will not be a text-mode GUI. 
> 
> Okay. It should at least exit gracefully when DISPLAY isn't set.
> 
> Pointing a text-mode web browser at http://localhost:631/ isn't a great option,
> but I can see that as an upstream problem.

Why not just use system-config-printer to configure the remote server?

So, redesign and re-write complete.  Please file further bugs separately.