AW: [Desktop_printing] Role of CUPS and error handling

Michael Sweet mike at
Sun Apr 2 11:24:28 PDT 2006

Robert L Krawitz wrote:
> ...
> Another option
> would be a thin glue layer that communicates with a print dialog
> running in another process (which would have legal advantages also for
> the non-FOSS crowd; it would permit a proprietary print panel to be
> used with a GPL application, since the actual print application would
> be running in another address space and the glue layer could be LGPL).

SGI did/does this for their print spooler.  Again, you have to copy
the option program from the server and it depends on having a binary
that will work on your OS/architecture...

Binary option panels/extensions are a dead-end...

>    > 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.
>>From a user standpoint or an architectural or network administration
> standpoint?

Architecturally.  From a user standpoint, we are dead-even for
GNOME/KDE apps and lagging behind for non-GNOME/KDE apps.  There are
definitely things we can do to improve the GNOME and KDE print dialogs,
and I'd like to see a standard print dialog that other applications
can use (basically, pipe output to the print dialog program)

 > What I see on Linux is that every application has its own
> print dialog; Mozilla is completely different from
> which is completely different from (ahem) the GIMP and so forth.  This
> is preferable to having the same print dialog with every application?

Run some Windows applications and observe the number of different
print dialogs you see.  Ordinary applications (Firefox, Word,
etc.) use either of two different "standard" Windows print dialogs,
while specialized apps (Illustrator, Photoshop, Quark, etc.) use
their own print dialog with a "setup" button that opens one of the
standard dialogs.

 > ...
>    In short, who (besides you) is looking for a solution that allows
>    them to specify custom linearization curves from every application?
> Interpret this as you will, but here are a few requests I've received
> recently.
 > ...

The first request was for printing from the Gimp, the second didn't
specify.  Given regisr's prior posts and the nature of the printing
(using the quadtone inks), I'd guess that the second request would
be for fine-art B&W printing of images.

Both situations do require some specialized UI, but that UI would,
IMHO, be inappropriate for a word processor or web browser.

FWIW, I'm not against providing these kinds of options or working to
support high-end use scenarios.  My questions and concerns are
driven by wanting to determine the actual requirements and use
cases, so that we can actually implement something that works for

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software

More information about the Printing-summit mailing list