Re: Re. inkjets: An open letter to Tom Lianza and Lars Borg
Re: Re. inkjets: An open letter to Tom Lianza and Lars Borg
- Subject: Re: Re. inkjets: An open letter to Tom Lianza and Lars Borg
- From: Robert Krawitz <email@hidden>
- Date: Mon, 19 May 2008 20:43:15 -0400
Date: Mon, 19 May 2008 17:17:48 -0700
From: Lars Borg <email@hidden>
Some concerns:
- It seems the proposed solutions will only verify that the same bits
are coming out now as during verification. So this won't help if I
have a new source profile, which means new source bits. Or I have a
printer that recalibrates itself when I install new ink cartridges.
Or I have a new printer or new supplies.
This particular solution is one that I'm using for Gutenprint
regression testing as part of development where my intention is to
make a major change to the underlying source that should not change
the output (defined for this purpose as "the byte stream send to the
printer") in any way. It may not work for any other purpose. In
particular, it won't work for any driver that uses true (pseudo)random
dithering, where the dither pattern may change from run to run. It
also won't work for drivers that do things like embed the date and
time (most Epson printers allow doing that, although I don't know what
it actually gets used for).
If the printer recalibrates itself when you install a new cartridge,
it may or may not have any effect on what the driver generates -- that
depends upon whether the printer tells the driver and the driver makes
use of that information.
Gutenprint's a bit different from typical vendor-supported drivers.
In particular, it's not OS-dependent, and the source base is identical
everywhere (the same code runs on Linux, Macintosh OS X, Solaris, BSD,
etc). This simplifies things a lot; the underlying driver library
exports a core API, and the wrappers that support particular
applications (CUPS driver, Ghostscript IJS driver, GIMP plugin) can
build on a stable base. On the flip side, we support a very large
number of printers with a lot of options (current 313 Epson printers
alone, 88 if you count functionally distinct printers, and over 1300
total). So if I'm going to make a pervasive change to the Epson
driver (like I'm currently working on), I need a regression test that
covers lots of ground that can be automated -- in this case, I'm
testing about 7200 combinations of resolutions, papers, etc. on the
Epson drivers alone.
My strategy here is to make the pervasive change, and then ensure that
there's no change at all via the regression test. After that, I'm
going to make changes that will actually cause certain kinds of
changes, for which purpose this particular test won't help me.
--
Robert Krawitz <email@hidden>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail email@hidden
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden