Re: [Gimp-print-devel] timeline on rinkj release

[Raph L. <ra...@ac...>]

Robert L Krawitz wrote:
> Well, let`s hope that the result is positive.  What could we do to
> maximize the probability of a favorable (to the free software/open
> source community) outcome?

I can't think of anything offhand. If you do happen to be in contact
with printer manufacturers, let them know that you prefer the work to
go ahead as GPL.

I'm not making an ironclad promise here, but from what I see now, it's
very likely it will go ahead as a GPL release.

> Is there any kind of interface improvement that you would require that
> if we were to implement ahead of time would assist you?  What I refer
> to specifically is changes to the call sequence to the print function
> or anything else defined in print.h (or in the less formal interface
> between the print functions and the dither functions, which needs to
> be tightened up) that would be of general applicability?

Yes.

The internal design of rinkj is extremely modular, and is based around
a RinkjDevice object (objects in C, with function pointers defined in
a public interface). There's also a similar object for writing raw
byte streams.

So, to print a ppm to an Epson printer, you create three objects, in
this order:

1. A raw byte stream writer object, which is (generally) piped to
   /dev/lp0.

2. An escp2 device object, which takes in four pbm-style images, one
   each for CMYK (or six for a photo printer). This object is
   responsible for converting these pbm images to printer escape
   codes.

3. A dithering object, which takes in four pgm-style images, one each
   for CMYK (or as above). All this object does is dither (it also
   applies a lookup table as it goes, so that 8 bpp is sufficient --
   an alternative and equally valid choice would be to bring in 16bpp
   input at this point). Dithering also performs scaling up.

4. A CMYK conversion object, which takes in a ppm-style image. It is
   responsible for RGB->CMYK conversion.

A key feature of this architecture is that you should be able to
mix-and-match as desired. For example, if your app happened to mix
line art and images on two different layers, you could do the
dithering on just the images, then combine in the line art later. I'm
also interested in making it easy to integrate with other imaging
api's (GhostScript comes to mind rather immediately).

Here's an idea. I could make a GPL release of the code with the fun
dithering stuff taken out and replaced with vanilla Floyd Steinberg.
Then we could both look at the code and discuss how to integrate it.
Even if there isn't an immediate GPL release of the full code, you'd
still get a reasonably well thought-through modular architecture. Does
this sound interesting?

I'm still hacking the code, and in particular don't have the api
nailed down for setting config params. So there's no special urgency
to get this code out.

Let me know what you think.

Raph

P.S. Anyone looked at the output of cat /proc/parport/0/autoprobe ? I
am fascinated by the idea of auto-configuring the driver from this
information.