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?

(Ghostscript folks, we're starting to talk about splitting up the Gimp-Print project into sub-components.)

From: Eric Sharkey 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 do now.

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 interesting stuff.

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.

Date: Sat, 06 Jul 2002 02:19:31 +0200 From: Till Kamppeter

The GIMP plug-in could well be part of the GIMP, but then users without printers need to install libgimpprint. Perhaps it is best when the plug-in would be a stand-alone package. Or when there is no libgimpprint and one compiles the GIMP, the plug-in will not be compiled.

That is, of course, if somebody doesn't rewrite the plug-in to not use libgimpprint at all. However, I think the best thing to do is for the GIMP's configure script to autodetect libgimpprint and build it if available (just like it does for, e. g. JPEG import/export).

So all in all I agree with your splitting suggested above. By the way, I will probably also split Foomatic: into the XML database, the databse engine (the stuff which generates PPDs and sets up queues), and the filter scripts. This will solve many updating problems.

Can you also think about how to handle generation of the XML database? We've never promised stability in terms of printers and supported printer functionality, and I think it's necessary for this stuff to be generatable on the fly.

Date: Sat, 06 Jul 2002 03:41:59 +0200 From: Till Kamppeter

> Can you also think about how to handle generation of the XML > database? We've never promised stability in terms of printers > and supported printer functionality, and I think it's necessary > for this stuff to be generatable on the fly.

As in my previous answer, I will ship an extra foomatic-database-gimpprint package which can evolve independent from the main database (foomatic-database).

The problem with this is that the foomatic data is intimately tied to the library version (in the future, hopefully we won't even need to rev the library to rev the printer data, but we'll see). So if somebody upgrades libgimpprint, they must be able to upgrade the foomatic database simultaneously.

Date: Sat, 06 Jul 2002 03:41:59 +0200 From: Till Kamppeter

> Can you also think about how to handle generation of the XML > database? We've never promised stability in terms of printers > and supported printer functionality, and I think it's necessary > for this stuff to be generatable on the fly.

As in my previous answer, I will ship an extra foomatic-database-gimpprint package which can evolve independent from the main database (foomatic-database).

BTW, one way to do that on an RPM-based system might be to have a post-install script that checks if foomatic is present, and if so runs the upgrade script.

Date: Sat, 06 Jul 2002 03:35:36 +0200 From: Till Kamppeter

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

It's in GhostScript, when its interface to the library does not change you can drop yours. And with the current development policy of GhostScript you would easily get a newer gdevstp.c in when it gets necessary. It should be a legacy interface, distros should drop it and use IJS instead. This would remove the dependency of GhostScript on libgimpprint, so packaging to make a consistent distro gets easier.

That suggests that we could drop it right now. IJS will have been available for at least 6 months by the time 4.4 (or 5.0) comes out, so we shouldn't need to support this beyond 4.2.

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

Yes a 4.4 would be good for it. Due to the new PPDish Foomatic I will probably also soon come out with 3.0 (and drop even 2.0).

This suggests a relatively near-term 4.4, without major API changes (and possibly without any API changes at all). It would primarily be a packaging change, with some minor new features. It could actually be called a 4.2 release, although I don't like the idea of doing major packaging changes during a stable series.

Date: Sat, 06 Jul 2002 16:35:49 +0200 From: Till Kamppeter

Robert L Krawitz wrote: > BTW, one way to do that on an RPM-based system might be to have a > post-install script that checks if foomatic is present, and if so runs > the upgrade script.

Which upgrade script? The GIMP-Print foomatic-generator?

Yes.

Date: Sat, 06 Jul 2002 16:53:46 +0200 From: Till Kamppeter

So the foomatic-database-gimpprint package contains only the Foomatic data generator and requires libgimpprint. The Post-Install script of libgimpprint checks the presence of Foomatic and the Foomatic data generator. When both are present, the Post-Install script deletes old GIMP-Print XML files, starts the data generator and foomatic-kitloads the resulting files. So a distro does not even need to ship the GIMP-Print XML files, they will be generated on the fly, during package installation.

That sounds almost right (unless someone installs foomatic after installing Gimp-print, and we can't guarantee ordering).

Date: Mon, 08 Jul 2002 09:06:00 -0400 From: Michael Sweet

Robert L Krawitz wrote: > ...
> 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.

Well, it's not just CUPS PPD files, but PPD files in general. Hopefully that will be resolved well in CUPS 1.2 (we might even be using some stuff that Apple has been using for a while in MacOS), but in any case it is just a matter of time before there are no more excuses... :)

Any idea about timing?

As for packaging the CUPS stuff separately and looking for libgimpprint (or gimpprint-config), that's something I'm prepared to do today, and we can bundle it with the standard CUPS distribution or as a separate download.

OK, we just have to work out the logistics. I'd rather take it out of 4.3 when you release a version of CUPS including it, and leave it in 4.2 (so people using newer versions of 4.2 with legacy versions of CUPS won't get screwed).

I think we need to leave genppd around somewhere, so that people installing new versions of libgimpprint can update their PPD files.