Gimp-print 4.2 is nearing release. It's hard to believe that it's been more than a year since gimp-print 4.0 came out; I didn't expect it to take as long. It's going to be a good release; we have a nice mix of new printers (particularly Epsons, since Epson is so much more helpful with what we really need), improved quality, and improved architecture. Roger Leigh, who joined after 4.0 came out after I found that he had done some work on an Epson utility, did a huge job creating a proper library from the core. And finally, Andy Stewart wrote a user's manual. That's one of the biggest improvements in 4.2. Pity docbook's so fragile, but it's worth it.
I would have liked to have done more architectural work, but 4.2 wasn't planned to be a major release, so we didn't expect to accomplish much. We accomplished more than we really planned, but we took a lot longer (I envisioned 6-9 months, and we're currently over 12). Some of it has been feature creep, but I don't think that that's the main problem; we've stayed within reasonable bounds. The big problem is that everything happens slowly, because nobody can really commit to anything, because paid work and such get in the way. The big architectural change happened early in the cycle, and all of the fallout was really over by early spring. Cleaning up the engineering of the documentation has taken some time, and a lot of that came in late, but that's as good a reason to hold a release as any.
We have 15 bugs open right now. The bug rate shot way up after beta-4, although some of that's simply pickier reporting on my part. There's one really critical one (more below), one that concerns me but I need to know how to try to reproduce it, two more easy fixes that I have out for review but that should never have gotten as far as they did before being found, and another one that just needs testing on a BSD platform. There are some other bugs that are definitely fixed, some that are low enough priority so we can go release without them (we've planned to, in fact), and so forth. So it's not quite as bad as it looks, but we do have a few stoppers yet.
Translation of PPD files
The nasty bug involves translation of PPD files. Another thing that we've done this time around is that we're translating Gimp-Print into a number of languages. One of the core gimp-print applications is a driver for CUPS driver. CUPS uses PPD files, and these files should be in the correct language for the user.
The PPD files are created at compile time, not at run time, and therein lies at least part of the problem. The internationalization mechanism (GNU gettext, or anything compatible) likes to find its message catalogs in certain places, and of course at compile time they aren't there. The POSIX-standard stuff seems to only like working in terms of valid locales, and there's no guarantee that the name of a language (e. g. "sv") will be the name of a valid locale. If it is, everything works; if not, it usually doesn't. The GNU gettext has an escape hatch: if you set the LANGUAGE environment variable, it just uses that without worrying about anything else.
The standard configure package has a --with-included-gettext option to use the gettext bundled with the package (in this case, we're bundling 0.10.40). I don't really like this, since it forces a fairly important decision on the user based on something that's only needed once (at compile time), but this would probably be acceptable, if it worked. Problem is, at least on the FreeBSD machine at Sourceforge, it doesn't! Even with --with-included-gettext, even with static linking, the PPD files just don't get translated! This causes six identical copies of the PPD files to get translated. When there are 133 PPD files per language (totalling 1 MB per language compressed), and when every one of these shows up in a menu for CUPS users, it's really quite unpleasant.
It's probably quite obvious from this that I am not an expert in this particular area. If anyone is, and would like to help us out, the bug in question is here.