New directions in gimp-print

[Robert L Krawitz <rlk alum mit edu>]

You folks might be interested in some new directions we're starting to
take as of gimp-print 4.1.3 (just released).

We've completely reorganized our source base, and we're now fully
leveraging the GNU build mechanism to create a shared library with the
applications (Gimp Print plugin and the CUPS driver; Ghostscript is
harder to bring into the fold) linked against it (thanks to Roger
Leigh for all of this work).  The shared library contains the drivers,
color machinery, and dithering core.

This architecture has a number of benefits:

1) The interface between the applications and the underlying driver
   becomes much more cleanly defined.  This will let us formally
   define the API to the printing library, which will stabilize the
   package in the long run.

2) It reduces the size of the distributed tarball (1.5 MB in 4.1.3
   vs. 2.7 in 4.1.2) and the disk footprint for a full installation.

3) With a common library, we can start defining shared data that lives
   in a known location (perhaps /usr/local/share/gimp-print).  This
   data could comprise things such as color profiles, sets of options,
   and so forth.  We don't really have any of this now, but we're
   discussing ideas for it.

We welcome any comments and feedback, as usual.

-- 
Robert Krawitz <rlk alum mit edu>      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 uunet uu net
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers