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 <rlk@xxxxxxxxxxxx> 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 lpf@xxxxxxxxxxxx "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
