I've made what I expect will be the last major changes to my version
of the print plugin for a while, and renumbered it.  It's at
http://www.tiac.net/users/rlk/print.tar.gz.

Notable changes:

1) All per-printer settings are now saved in the printrc file.  This
   isn't perfect yet -- the settings for the File printer aren't saved
   now, and the scaling setting isn't correctly saved for printers
   that you haven't accessed (they default to 5% of the image size,
   which is just silly).

2) I've moved all glib, gimp, and gtk+ code into print.c -- print.h,
   print-escp2.c, print-ps.c, print-pcl.c, and print-util.c no longer
   have any references to anything not in standard C header files.
   The purpose of this is to improve portability if/when I or someone
   else wants to make this into a more general rendering engine.
   Everything is handled by means of (what amount to) method calls on
   Image objects, which encapsulate the actual GIMP calls.

3) I've removed all of the 8-bit rendering code -- it now does
   everything in 16 bit.  This makes for much higher quality in some
   circumstances, particularly light tones.  Actually, the 8-bit code
   was unused, but tonight I removed it (although there are still a
   few routines #ifdef'ed out in print-util.c).

4) I've updated all of the copyright notices to refer to Mike Sweet
   and myself, and bumped the version to 3.0 (which may be a bit
   presumptuous on my part :-) ).


Notable issues with the current code (I consider all of these minor).

1) print.c is a real mess right now.  All the settings-handling code
   is ad hoc and very ugly, and there's a lot of knowledge scattered
   about the code.

2) As noted, the settings save/load code isn't perfect.  It's OK for
   beta (or development), but not really for a release.

3) Printing at 360 dpi (on the Stylus Photo) yields slightly reddish
   grays.  I'm not quite sure what to make of it.  360 dpi is proofing
   resolution, and I'm not all that worried about perfection there
   (I'm more concerned about a much smaller greenish or cyan cast at
   720 dpi, and a possible slight blue-magenta cast in lighter tones).

4) The K->CMY code is distinctly tuned for the Stylus Photo EX right
   now.  Sorry, I don't have another color printer to play with.

5) The Stylus Photo printing has become very slow for some reason (at
   least at 720 dpi).  On the other hand, the microweave-induced
   banding has entirely vanished, yielding much (arguably
   spectacularly) better quality.  I'm not positive exactly what did
   this, but it's not at the top of my list of priorities to "fix".
   If it takes 30 minutes to print a really high quality full-page
   print that doesn't seem so bad.

6) Entirely get rid of the 8-bit rendering when the 16-bit rendering
   is tested for all of the various rendering functions on a
   reasonable variety of hardware.


Notable things for the future (until it's replaced by a real printing
architecture):

1) User-defined pseudo-printers (essentially, sets of settings) and
   default settings for newly-defined printers (currently it just uses
   defaults of 100% for everything).

2) Printer-specific settings.  For example, for the Stylus Photo allow
   specification of microweave mode, and softweave if that's ever
   implemented (softweave is reasonably fast, but not especially high
   quality).  This would solve the issue of slow printing, since the
   user would have more options to select from.

3) More general rendering methods (currently everything is
   scan-line-in/raster-out, which makes it harder than it should be
   to do clever dithering or print to devices that expect multiple
   raster lines grouped together).  Currently extremely light tones
   show shadowing artifacts from the unidirectional error diffusion.
   I've improved it some by randomizing the print threshold, but it
   isn't perfect.

4) Text boxes for absolute size/positioning, rather than just scaling
   and a move-rectangle-in-box interface.

5) More devices!  More devices!  And dynamic loading of drivers (which
   might be overkill for this application, but it sure would be nice
   if Ghostscript could do it!)

6) Specific improvements in rendering quality are always a Good Thing
   (tm).

7) Merging dither_cmyk4_16 (4-color, 4-level) with dither_cmyk16
   (6-color, 2-level).  This will be required to properly support the
   Stylus Photo 750/1200 and probably some of the other new-generation
   photo printers.  Likewise, dither_black4_16 with dither_black16.

8) Dark midtones show some splotching caused by mixing CMY and K.
   Generally this manifests itself as somewhat washed-out colors and
   pale dark grays, rather like a print from an underexposed
   negative.  I've had enough beating my head against this for now.


Notable issues for me:

1) I want to cut down on my ink and paper expenditures.  Ink
   cartridges are expensive, and I've already run through four color
   cartridges and a black one.

2) I want my life back.  I'm spending too much time on this project.

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

Reply via email to