AW: [Desktop_printing] Role of CUPS and error handling

Robert L Krawitz rlk at alum.mit.edu
Sun Apr 2 10:40:19 PDT 2006


   Date: Sun, 02 Apr 2006 00:29:48 -0500
   From: Michael Sweet <mike at easysw.com>

   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. (!)

The latter is a Windows issue.

   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!)

I don't think that we necessarily need to go all the way to "driver
provides the UI", but having a richer set of primitives to work with
(including curves and arrays) would make it practical to create a
generic print UI that supports these advanced uses.  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).

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

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

But they want the driver to be nice and linear, don't they?  That may
be "dumb", but the driver still has to at least a little bit of work
to generate linear output from linear input.  I guarantee you that a
*really* dumb driver, that doesn't even do linearization, will produce
unsatisfactory output; you can do exactly that in Gutenprint by
selecting Raw color correction.  You can also select non-linearized
density-corrected, or linearized density corrected.

Now, they may well not want to have to deal with the linearization
manually (they want the driver to Just Do It), which isn't
unreasonable.  However, I'd expect that when they have a new kind of
paper (or their printer ages over time), they can't avoid doing this
kind of calibration.  Possibly the right thing there is for someone to
stick the calibration into the PPD file or something, but it still
needs to be there.

Incidentally, we do tell people who want to use ICC profiles that they
should use Uncorrected (i. e. linearized density corrected) mode and
use defaults for the other parameters, for exactly the reason you
suggest.  But that doesn't cover everyone.

Workflow setup seems to be a bit of a black art, from what I read on
the epson-inkjet at leben.com list.  Nobody seems to be really satisfied
with it; they grin and bear it.

   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.

================================================================
From: Robert L Krawitz <rlk at alum.mit.edu>
To: ttrostel at comcast.net
Cc: gimp-print-devel at lists.sourceforge.net
In-reply-to: <44248D27.1000705 at comcast.net> (ttrostel at comcast.net)
Subject: Re: [Gimp-print-devel] R1800 - Linearization etc.
Date: Sat, 25 Mar 2006 09:50:53 -0500

   From: "Thomas M. Trostel" <ttrostel at comcast.net>
   Date: Fri, 24 Mar 2006 19:21:59 -0500

   Is there anywhere in the code to custom modify the linearization
   curves for the Epson R1800 on specialty paper?  I'd like to use my
   spectro to try improving print quality for some fine art papers
   such as Crane Museo etc.

You can do it in the GIMP -- the color adjustment window gives you
direct access to the curves (or at least to the CMYK curves -- the red
and blue are derived directly from the post-linearization CMY
curves).  Unfortunately, the GIMP can only handle 8-bit images.

   A second question is if there is any schedule for implementing ICC
   style profiles.

No, although it's been high on our list for quite a while (nobody to
do it).  However, PhotoPrint supports ICC profiles along with 16-bit
images.  Alastair, do you have a plan for implementing curves in
PhotoPrint?
================================================================
From: regisr <regisr at regix.com>
To: gutenprint <gimp-print-devel at lists.sourceforge.net>
Subject: [Gimp-print-devel] Stupid questions from me ... !
Date: Tue, 7 Feb 2006 00:08:40 +0100

Hello,

Who can explain to me how to use the values Gray1Transition,
Gray2Transition and Gray3Transition ?
(ie "Dark Gray Transition", "Mid Gray Transition" and "Light Gray
Transition" )

I can't find this in the documentation.

I try to use the black curve to correct my print but is it the right
solution?

Configuration: epson 1160 / inks quadtone (with quadtone selected)

-- 
<regisr>
================================================================
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



More information about the Printing-summit mailing list