The problems Raphael is having building Gimp-print and Gimp 1.2.3
suggest to me that the various components that make up the package may
not be grouped together most effectively.
Gimp-print includes the following components:
1) libgimpprint, the core driver component, which implements the
actual printer driver and provides an API that applications
(typically spooler-specific driver executables) can link against.
2) The Gimp Print plugin
3) CUPS driver
4) Traditional Ghostscript driver
5) IJS-based Ghostscript driver
6) Foomatic data generator
7) escputil (Epson Stylus printer management utility)
8) lexmarkutil (Lexmark printer management utility)
9) Unit tests
10) Developer tools (unprint, parse-escputil)
11) Sample images
12) User manual (describing the Gimp plugin, configuring the CUPS
driver, and escputil)
13) Developer's manual
14) Test pattern generator
This covers a lot of territory, perhaps too much. Certainly there are
some design choices, particularly in 4.2, that are dictated by our
project being the support project for the Gimp print facility, but are
now coming back to bite us. Certainly the idea of the Gimp generating
raw printer output seems strange (to me, at any rate). There are some
other oddities, such as escputil, that are more closely related to the
notion of a printer driver but which really operate independently of
the rest of the package.
One could argue that libgimpprint would make a perfectly coherent
package strictly on its own, even though it's completely useless
without anything else using it. After all, libc is clearly a coherent
package even though it does absolutely nothing without applications
that link against it. The various library clients (CUPS driver and
PPD generator, the Ghostscript drivers, the Foomatic data generator,
and the test pattern generator) are completely independent of one
another and most end users (and possibly even packagers) will only be
interested in one. The downside to this is that it would make
building and installation more of a hassle (not really more
difficult), since it would require downloading at least two packages.
I'm not convinced that we really want to own escputil and lexmarkutil
at all. It may well make more sense for, say, Jean-Jacques Sarton to
package them up with his mtink utility (which is a graphical utility
to manage Epson printers).
The Gimp plugin is a hard case. It's just not clear to me at all
where it really belongs and what it should be. Some of its
functionality (such as the preview, and the color control sliders)
would be hard to reproduce if it were just a PPD-based printing
client, but except for the preview window that's more a limitation of
how at least the CUPS PPD files work than anything else. The preview
functionality probably deserves to be a full-fledged widget in its own
right, and a lot of other applications could benefit from it.
So what do people think? Should we split Gimp-print (4.3 and beyond)
up into a collection of smaller packages, and what should they be?
Should we turn the Gimp plugin over to the Gimp team? Should we spin
off escputil?
--
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
Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
