AW: [Desktop_printing] Role of CUPS and error handling

Kurt Pfeifle k1pfeifle at gmx.net
Sun Apr 2 15:43:45 PDT 2006


On Sunday 02 April 2006 04:45, Robert L Krawitz wrote:


> One thing I've noticed on Windows is that when you go to print from
> any application you get a driver-specific print panel. 

Not by necessity. But it is an option for printer driver developers.

> I'm not 
> familiar with the Windows printing system internals, but that would
> suggest that the driver provides at least some of the UI itself.

Some indeed do. Partially, because on the Windows platform, vendor
competition also does involve competing on the field of new 
proprietary print file formats, or closed extensions to existing open
ones. Partially, because they want to closely integrate their bidi
communication with the device (mostly based on SNMP, but very often
only fully function with, again, proprietary extensions to SNMP).

This is implemented by adding one or more DLLs into the driver, 
which complement the existing standard DLLs (or replace them
altogether).

Since up until Windows 2000, printer drivers did run in Kernel space,
this made for some very reknown causes for Blue Screens of Death.

Windows 2000 and XP introduced a new architecture where printer 
drivers now run in user space; but that meant all drivers needed
re-writes; and since that did not happen for old devices, there
is also a "compatibility mode" which allows to run old drivers
(still in kernel space of course), with all the known problems.

So making it a standard to add UI elements which are provided by
the driver isn't causing me yelling "hooray!"   ;-)

{...]

> We aren't going to make inroads into the desktop by simply matching
> Windows in this area (printing in general).  We need to provide a more
> compelling proposition. 

I fully agree!

And I think we are already on a very good road here. In fact, it is
my deep conviction that (largely due to CUPS), we already have a
platform that is superior from an architecture point of view. Every 
time I am able to demo CUPS and KDEPrint in a network environment 
with previous Windows or Unix print frustrations, the admins are 
simply blown away by the power of that combo, and what it already
offers without any additional, specialized printing software... 
(Gnome-Print is currently about to fill the gap.)

Take CUPS alone: its "printer browsing" features make printing for 
clients so much easier to handle; its modular design, which lets 
you plug in all kinds of self-written little scripts and tools as
filters or customized backends lets you meet many special needs 
which are just impossible to be met on Windows without major closed
source software writing. (I say "closed source software writing",
because if a Windows solution is needed, companies usually hire a 
software development company to create it.)

KDEPrint as we know it now is already 5 years old. And yet it is
more powerful for common use than what Windows provides. (Granted,
it has become a bit out of sync with CUPS developments, and there
are about half a dozen CUPS print options which are not supported
by kprinter because development was nearly dormant for the last 2 
years; also, the KDE GUI does not any longer support setting of
all options for cupsd.conf -- so for now I've stopped promoting
it to my customers as a tool that lets them remotely configure
their CUPS servers... Now with CUPS-1.2 being rolled out that 
missing piece will really start to hurt KDE...).

> While I will grant that very few users want 
> to manipulate linearization curves, it's not going to be very
> compelling to tell people that they have to give up their current
> special application for a new special application.  It has to outright
> blow Windows out of the water in this regard for it to be compelling.

Believe it or not: I have heard already various times from paying 
customers exactly this phrase, describing it as a fact that "CUPS
printing blows Windows out of the water"  ;-)

It doesn't mean that there is nothing left to do; on the contrary.
On the user level, we are still quite weak; our GUIs still suck too 
much (just look at the horror Firefox tries to sell us as a "printing
dialog...).

But that is exactly one of the topics to be tackled by the upcoming
summit. And the "Portland Project" is about to find a way how a
better integration of various desktop services (including printing)
can happen in the future. This is also to serve third party, ISV
products who should be able to request a printing dialog, where they 
can pipe their printjob in; the ISV should not need to know about
KDEPrint or Gnome-Print; the application should work the same way
inside both environments; if a user prefers Gnome, he should be able
to get his familiar dialog with all bells and whistles; likewise for
the KDE user. 

Cheers,
Kurt



More information about the Printing-summit mailing list