The current Gimp plugin (3.0.5) is a stable release at this point. I
will accept bug fixes, and support for new printers only if these can
be expressed in terms of functionality already in the plugin.
I'm starting work on a new development release (3.1) that will lead to
a 3.2 release. The goals for 3.2 currently are:
1) Support for more printers. I particularly want to support the
current generation of Epson printers (440/640/740/900/750/1200) and
Canon printers, since these seem to be among the more popular
printers around, but if anyone wants to contribute a driver for
something else, please feel free to do so.
Note that my only printer is currently an Epson Stylus Photo EX, so
I need help here. Testers will be welcome, but I'd like people who
have one or more of these printers (in particular, the 740, 900,
750, or 1200) who are not afraid to dig into the innards.
2) Clean up the dialog. The dialog is currently a real mess. For
one, the save settings stuff really doesn't work correctly. There
are a number of other things I'm considering here. Anyone who
actually understands human factors should feel free to contribute.
3) Start the process of decommissioning the plugin (more or less)
altogether :-) In other words, this business of each application
supplying its own printer driver is nuts, but I've read a lot of
comments that Ghostscript's dithering is awful, and that that
really isn't the fault of the individual output drivers within
it...
4) Clean up the configuration process so that it really can be built
as a standalone plugin or as part of the Gimp distribution.
5) Performance improvements consistent with high quality. I'm willing
to consider high performance, reduced quality modes as long as the
sacrifice in development effort isn't too high, but I think that
for the Gimp the emphasis should be on high quality output rather
than fast rendering time.
6) Support for 16 bit Gimp (let's lead the way rather than follow).
7) Work with printer manufacturers whenever possible, and try to sell
them on opening their own drivers.
8) More separation between the rendering engine and the printer
drivers. I've separated the drivers and engine from the UI in 3.0;
in 3.2 I want to further break things down to make it easier to add
new stuff.
9) Quality improvements. This is a matter of taste; with some
printers I've seen that it's possible to improve quality in one
dimension (e. g. speckling) at the expense of something else
(tonality and hue continuity). I'm a photographer (serious
amateur) myself, and my bias is toward good tonality and color at
the expense of some grain, but others disagree. Perhaps this
should be configurable if we can't come up with algorithms that
allow us to do both well.
I will be putting the 3.1 development tree on Sourceforge as soon as I
get to a reasonably stable point (i. e. things compile). Note that
early 3.1 releases may have lots of regressions; I'm working on
multibit pixels right now...
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton