(Ghostscript folks, we're starting to talk about splitting up the
Gimp-Print project into sub-components.)
From: Eric Sharkey <[EMAIL PROTECTED]>
Date: Fri, 05 Jul 2002 20:26:16 -0400
My two cents is to spin off what you can provided you can find
interested new maintainers. From the point of view of a
distributor/packager, smaller more self-contained packages are
easier to handle. For example, as a Debian maintainer, I can't
upload to Debian new releases of escputil without also uploading
new libgimpprint, cups drivers, etc. Everything that builds from a
single source tarball has to be updated together. For most
packages this isn't a big deal, but for gimp-print it's starting to
get a little silly.
That's the question I should have asked -- what's the best thing for
the packagers, since core Gimp-print isn't really an end-user
package. Sounds like you and Till are in rather violent agreement
here. I'm not sure that that's what I had expected, but it certainly
seems to confirm the idea that it should be split.
Would it make sense to split each of the high-level drivers -- CUPS,
IJS, and traditional Ghostscript -- into its own package? It sounds
like you and Till both think so.
So with all this, one possibility would be:
1) libgimpprint (including the current src/main, include/gimp-print,
src/testpattern, test, and the developer's manual). I think that
the test pattern generator should be included with libgimpprint as
a "sample Gimp-Print application". I imagine that distributors
would put this into a libgimpprint-devel package, along with
gimpprint-config, gimp-print.h, and possibly the developer's
manual. We might include the sample images here; they'd probably
go into a developer sub-package since they're most useful for
people supporting new printers. The developer tools are included
in the test directory; we might want to move them within the core
package (or do we want to split this into libgimpprint and
gimpprint-utils?). The Gimp-Print project would clearly own this.
2) gimpprint-cups -- the CUPS driver (rastertoprinter) and PPD
generator (genppd). I'm starting to think that we're using genppd
all wrong -- rather than generate the PPD files into a directory
within the build tree, and then copy them into the installation
directory, we should simply generate the PPD files into the CUPS
PPD area. This might solve the long-standing translation problem,
since the message catalogs would already be installed correctly
into the filesystem, and we wouldn't have to do the silly hack we
It's unclear to me that things like commandtoepson, commandtocanon,
cups-calibrate, canon, and epson belong in Gimp-print at all.
These look to be core CUPS functionality, and the potential for
collision is high. For that matter, "rastertoprinter" should
probably be "gimpprint-rastertoprinter" or the like. Mike?
Perhaps we would own this, or perhaps the CUPS project would. CUPS
is quite stable, although 1.2 is going to have some new and
3) The old-style Ghostscript driver (stp), delivered as a patch to
Ghostscript. That is, if we don't want to deprecate this
altogether in 4.3, now that IJS functionality is reasonably mature
in GNU Ghostscript.
I would much prefer to see the Ghostscript project own this. They
already have it in 6.53 and newer GNU releases, and we'd just as
soon get rid of it.
4) The IJS Ghostscript driver. Other than ownership, this is about
the most straightforward piece of the lot. Both Gimp-print and IJS
are evolving interfaces, so maybe this would need to be a separate
project maintained by a cross-functional team.
5) Foomatic. The key here is really the foomatic data generator. The
foomatic data generator actually contains a number of Gimp-print
client applications that extract data from the (internal) database
via supported interfaces. Foomatic is also a somewhat evolving
interface. Till, any more thoughts about this? Ownership?
6) escputil and lexmarkutil. These have nothing to do with
libgimpprint at all and don't even link against it. We've owned
these because we wrote them, but they would really fit much better
with mtink if Jean-Jacques wants to take them in.
7) The Gimp Print plugin. This one's a real hairball. We own it
largely for legacy reasons. It is currently a client of
libgimpprint, but as a result there are a number of design
decisions in libgimpprint that wouldn't have been made otherwise
(such as the way image position and size are specified, the way the
color functions are exposed, and the presence of the Postscript
family driver). There are real issues of ownership, what it should
be, and whether it should even be a libgimpprint client at all.
8) The user manual. A lot of its raison d'etre goes away if we split
everything off, since then Gimp-print won't even be a user-visible
package at all. However, there's far too much good work there for
it to go away. Perhaps it needs to split up, and the Gimp portions
should go with the Gimp plugin, the CUPS portions should be
absorbed by the generic CUPS documentation, and the escputil
portion should go with escputil.
Thoughts? This is a fairly radical proposal in some ways. However,
the current 4.3 API is still completely compatible with 4.2, and
perhaps we should do a 4.4 that's simply 4.2 (or 4.3 as it now stands,
with things cleaned up) with this split.
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]
Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
Gimp-developer mailing list