AW: [Desktop_printing] Role of CUPS and error handling
mike at easysw.com
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
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 OpenOffice.org
> 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
> 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
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 http://www.easysw.com
More information about the Printing-summit