1 Dec 2000 rlk   » (Journeyer)

Gimp-print 4.0

We're on the 5th minor release of 4.0 (4.0.4). There have been two bugs that we've fixed in the core (one for the HP 1200C, and one in the color conversion code); the rest of the bugs have been in the Ghostscript or CUPS drivers. That's about what I expected; the core has had a lot of work, while the drivers haven't been exercised as much. What's annoying is that we could have caught a lot of these through better testing. There were a few fairly nasty ones.

One issue that we're considering with 4.0 is how much to back port from the development mainline. There's one particular improvement (support for C-RET mode on higher end HP inkjets) that quite a few people want, but it needs more work on the mainline. Another issue is the color quality. There are some fairly serious color issues with 4.0: reds are rather orange, blues are rather violet, and greens are somewhat straw-colored. The improvement on the mainline is somewhat ad-hoc: a hue map. This does corrections in HSB space rather than RGB or CMY, but it does a remarkably good job of correcting the gross color errors. It won't correct other errors, though.

Gimp-print development

I consider the hue mapping described above to be purely experimental color correction. We really need a better color model. This will presumably happen over time. Nonetheless, reaction to even this has been very positive. I've really come remarkably close to matching my display.

Andy Thaller has been putting quite a bit of work into the Canon driver. He's borrowed the ink model from the Epson driver. As long as we can find enough testers, we should be able to greatly improve that driver. It still won't match the Epson driver very soon, because Canon won't give out the kind of information we need to put the printer in the very highest quality modes. Enough people have commented on the printer vendor situation, so I'll simply reiterate: printer vendors who hand out information will find that the free software community will supply high quality drivers for their printers, while printer vendors who don't will find the world passing them by.

We're also talking with the Omni folks from IBM about their approach to the metadata problem. There's a huge amount of information that goes into printing something, and we only expose a very small part of that to users. This is unfortunate; it makes it much harder for users to tune their printout, using all of the settings that the dither and color code export. The Omni team has put a lot of effort into the architecture of their system, and not as much into quality; we've put tremendous effort into quality, but our architecture is weak. There should be a lot of possibilities for synergy here.

We're also trying to decide what 4.2 should look like. I had envisioned it as a fairly large release, converting to an internal CMY(K) model, with an external metadata representation, and the like. I'm having a bit of a change of heart about this. Perhaps it might be better to make it a fairly conservative release, doing something (not necessarily the ultimate) about the color quality, fleshing out the drivers, and such, and hold the really big stuff for another round.

gtaylor is working on the Foomatic stuff so that we can version it. We've already diverged enough from 4.0 so that the 4.0 Foomatic database won't work with the mainline. What I really want, though, is to be able to generate the foomatic data files programmatically, rather than having to download the tarball from linuxprinting.org. In addition to being slow, and bulking up the release, it's not very flexible.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!