AW: [Desktop_printing] Role of CUPS and error handling

[Michael Sweet]

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.  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.

Yes, and this causes many stability problems on Windows... :(

Windows drivers are composed of two sets of DLLs (the driver or
renderer part, and the UI part), one or more help files, and zero
or more data files.  All of these files are duplicated for each
architecture and version of Windows.

The UI DLLs are loaded by the print dialog and run in the
application's process and address space.  A buggy UI DLLs can crash
an application and will usually require that you reboot to clear the
DLL from memory. (!)

Apple has support for UI plug-ins, called Print Dialog Extensions,
or PDEs.  They also run as part of the application and can cause an
app to crash.  Fortunately, you don't have to reboot to clear a bad
PDE...

In order for any of these special driver UIs to be available, they
have to be copied from the server to the client; if you update the
driver on the server, you have to manually update it on the clients.

If the server doesn't have a driver module for the right OS or
architecture, then you are SOL.

I sincerely hope that we can avoid print dialog plug-ins on Linux
(and by extension, all OS's that use a free software desktop).
Rather, if we want to support this functionality, we should do it
using a platform-neutral format, something like Mozilla's UIL
(although I am not recommending that specifically - the lighter
weight, the better!)

> 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

I believe we are already years ahead of Windows.

> compelling proposition.  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.

Why this feature?  If you are doing specialized printing, then you
probably have a workflow setup that manages all of this stuff, and
probably using a custom/specialized application.  ALL of the high-end
print shops I work with use ICC profiles exclusively, and are not
asking for the kind of options Gutenprint provides.  Rather, they
want the driver as "dumb" as possible so they can push color data
without "interference" from their app.

In short, who (besides you) is looking for a solution that allows
them to specify custom linearization curves from every application?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com