gimp-print-devel

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

[Robert L K. <rl...@al...>]

   Date: Fri, 24 Mar 2000 12:28:49 -0800
   From: Raph Levien <ra...@ac...>

   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?

Yup.  It would certainly give us other ideas.

   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.

It doesn't work for me, unfortunately:

# cat /proc/parport/0/autoprobe 
MODEL:Unknown device;
MANUFACTURER:Unknown vendor;

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

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.

[Gimp-print-devel] RE: Membership in HP Solution Provider Program

[Eddie M. <ed...@mn...>]

On Fri, 24 Mar 2000, *** wrote:

> In regard to acceptance, Affiliate membership is available online in real
> time (the applicant must accept our program terms and conditions during the
> application process).  Once the process is complete, the member has
> immediate access.
> 
> Please return to our web site and retry the application process.  Keep in
> mind that you should be using version 4.0 or later of Netscape, Internet
> Explorer, or similar browser software.
> 
> Regards,
> 
> HP Printing and Digital Imaging Solution Provider Program
> http://www.hp.com/go/solutions

Dave, could you, the Ghostscript maintainer, and any others who wish give
this a try? And let us all know if all the latest PCL docs are revealed?

I think I don't have my Mandrake 7.0 E-mail configged yet.  So I'll try
again after I figure that out. 

------------------
Eddie Maddox
ed...@mn...

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

[Robert L K. <rl...@al...>]

   Date: Thu, 23 Mar 2000 11:52:03 -0800
   From: Raph Levien <ra...@ac...>

      I just wanted to update you guys on the timeline for the release of
   the rinkj code. My friends at Artifex (the people who license
   GhostScript) are busy shaking down the printer manufacturers to see if
   they are interested in funding the work. After four weeks, we're going
   to see if there's a compelling business reason _not_ to release as
   GPL, then almost certainly go ahead.

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?

      In the meantime, I'm going to keep hacking on the driver,
   concentrating on tunability for the RGB->CMYK conversion. Thus, when
   the code is released, it should be in pretty good shape. One of the
   things I'm seriously considering is building a web-accessible database
   of profiles for all the printer/resolution/mode/paper combinations.
   That should be fun!

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?

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] timeline on rinkj release

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

Hi Gimp-print people,

   I just wanted to update you guys on the timeline for the release of
the rinkj code. My friends at Artifex (the people who license
GhostScript) are busy shaking down the printer manufacturers to see if
they are interested in funding the work. After four weeks, we're going
to see if there's a compelling business reason _not_ to release as
GPL, then almost certainly go ahead.

   In the meantime, I'm going to keep hacking on the driver,
concentrating on tunability for the RGB->CMYK conversion. Thus, when
the code is released, it should be in pretty good shape. One of the
things I'm seriously considering is building a web-accessible database
of profiles for all the printer/resolution/mode/paper combinations.
That should be fun!

   I'll keep you guys posted about any further developments.

Take care,

Raph

[Gimp-print-devel] Some gui changes commited

[S. M. <sm...@rn...>]

I just did a commit for the first stage of the gui cleanup.  The major
changes are that the sliders for adjusting color, saturation, etc are
now in a popup called by clicking the adjust color button near the
bottom.  This popup is not actually destroyed until the main dialog is,
but clicking its dismiss button will unmanage it to get it out of the
way.  I still have to figure out how to center the dismiss button.

Still to come: pulling all the gui code from print.c (no visible
changes), trying to tighten up the layout, and putting in a scrolled
list instead of an option menu for printer types.

Steve
-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

Re: [Gimp-print-devel] colorfunc()

[Robert L K. <rl...@al...>]

   Date: Wed, 22 Mar 2000 14:27:26 +0000
   From: Dave Hill <da...@mi...>

   Do any of the various colorfunc routines have any random element
   in them? I looked quickly and couldn't find any. If this is the
   case, then surely it is more efficient to code this as:-

	 if (errline != errlast)
	 {
	   errlast = errline;
	   Image_get_col(image, in, errline);
	   (*colorfunc)(in, out, image_height, image_bpp, cmap, v);
	 }

   so that the colorfunc is only called once instead of repeatedly
   for the same input line.

   Might shave a bit off the processing time if the image is being
   expanded a lot.

True.  The runtime is dominated by the dither, but this would save a
bit of time.

[Gimp-print-devel] colorfunc()

[Dave H. <da...@mi...>]

I was just idly wondering about this bit of code:-

      if (errline != errlast)
      {
        errlast = errline;
        Image_get_col(image, in, errline);
      }         
    
      (*colorfunc)(in, out, image_height, image_bpp, cmap, v);

that appears in the various printer drivers.

Do any of the various colorfunc routines have any random element
in them? I looked quickly and couldn't find any. If this is the
case, then surely it is more efficient to code this as:-

      if (errline != errlast)
      {
        errlast = errline;
        Image_get_col(image, in, errline);
        (*colorfunc)(in, out, image_height, image_bpp, cmap, v);
      }

so that the colorfunc is only called once instead of repeatedly
for the same input line.

Might shave a bit off the processing time if the image is being
expanded a lot.

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] Printing from GIMP to Epson Stylus Photo 700

[Robert L K. <rl...@al...>]

   From: geo...@me...
   Date: Tue, 21 Mar 2000 21:52:21 -0800 (PST)

   I've successfully installed print-3.1.1 with GIMP 1.04.  Now
   whenever I try to print I get the following e-mail message:

	   Your printer job (stdin) 
	   could not be printed

Check the command that the plugin is using to print your job.  You can
find it from the "Setup" box in the upper right hand corner.  If it's
using lp -s, see if using lpr -l instead helps.

   I am using Ghostscript as my printer filter.  How should I
   configure it for use with print-3.1.1 ?  Also, how does print-3.1.1
   propagate the parameters specified in the print dialog
   (e.g. resolution) to the Ghostscript printer filter ?

It normally prints raw, using either lp -s or lpr -l, so the output
doesn't get filtered.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Espon Stylus Color 640

[Robert L K. <rl...@al...>]

   From: "David Clark <David Clark" <si...@te...>
   Date: Tue, 21 Mar 2000 20:34:30 -0800 (PST)

   I noticed on your Supported Printers page that the Epson Stylus Color
   640 is listed as 'needs testing'.  I have this printer, Gimp-Print
   3.12 installed, and plenty of ink and paper - I'd love to help.

   I'm not too knowledgable about printing - I can't distinguish
   'perfect' from 'good enough' without some guidance.  Are there any
   test images that members of the devel team have been using to judge
   performance?

It's very subjective.  We need people's opinions about print quality
in addition to objective testing of the specific features.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Printing from GIMP to Epson Stylus Photo 700

[<geo...@me...>]

  I've successfully installed print-3.1.1 with GIMP 1.04.  Now whenever
I try to print I get the following e-mail message:

	Your printer job (stdin) 
	could not be printed


  I am using Ghostscript as my printer filter.  How should I configure it
for use with print-3.1.1 ?  Also, how does print-3.1.1 propagate the
parameters specified in the print dialog (e.g. resolution) to the Ghostscript
printer filter ?



  George


-- 

[Gimp-print-devel] Espon Stylus Color 640

[David C. <D. C. <si...@te...>]

I noticed on your Supported Printers page that the Epson Stylus Color
640 is listed as 'needs testing'.  I have this printer, Gimp-Print
3.12 installed, and plenty of ink and paper - I'd love to help.

I'm not too knowledgable about printing - I can't distinguish
'perfect' from 'good enough' without some guidance.  Are there any
test images that members of the devel team have been using to judge
performance?

-- 
------------------------------------------------------------------------
David "Futility [D!]" Clark  | Note: all persons, living and dead, are |
 si...@te...           |  purely coincidental. - Kurt Vonnegut   |

Re: [Gimp-print-devel] Magic squares

[Karl H. K. <kh...@kh...>]

Here are some "Magic Square" links:

http://MS.houstonisd.org/RevereMS/students/student_old/ar.html

Karl Heinz

On Tue, Mar 21, 2000 at 10:02:57PM -0500, Robert L Krawitz wrote:
> Is anyone here familiar with the generation of magic squares
> (particularly "most perfect" magic squares, where each 2x2 block sums
[ ... ]=20


--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] Another idea (fractals?)

[Robert L K. <rl...@al...>]

The fact that I'm trying to get the same amount of ink deposited on
the paper on all scales also suggests the possibility of using some
kind of fractal for that purpose...

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Magic squares

[Robert L K. <rl...@al...>]

Is anyone here familiar with the generation of magic squares
(particularly "most perfect" magic squares, where each 2x2 block sums
to the identical value)?  I have some ideas about using magic squares
to improve dither quality, but I need to generate some to use a
matrices for that purpose.  They need to be linear (i. e. using a
sequence of numbes between 0 and 255, not using primes or anything
else).

Actually, what I want is something a bit more than that, even: I want
four magic squares that when stacked are "magic" in the third
dimension, too.  Better yet (if it's possible) would be for three of
the four to have the same 3D sum, as well as all four.

Even better would be 16x16 squares, where each 2x2, 4x4, and 8x8
sub-block sum to the same value (obviously each 4x4 block will sum to
twice what each 2x2 block will).

They don't actually have to be absolutely perfect, but the closer the
better.

The specific idea right now is to use this to implement variable
density (the current implementation of density is broken, even though
it generally behaves fairly reasonably).  So what I want to do is drop
some number of dots depending upon what the chosen density is.

The reason I'm thinking of this kind of super-perfect magic square is
so that any given region of the paper will receive on average the same
amount of ink.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Gimp-Print 3.1.2

[Robert L K. <rl...@al...>]

This is to announce the release of gimp-print (the Gimp Print plugin)
version 3.1.2.  This is a development release.  The release notes
follow:

1) Better dither quality.

2) Dither is optimized for several different types of images
   (photographs, continuous-tone images such as charts, line art, and
   very fast pure black/white rendering).

3) Tweaking of the GhostScript driver.

4) Epson Stylus Color 440 prints in softweave.  In general, most Epson
   printers are more reliable.

5) Preliminary support for more Hewlett-Packard printers.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Deskjet 9xx series

[Dave H. <da...@mi...>]

I have submitted the addition of the Deskjet 9xx series to the
PCL driver. In the absence of any hard facts so far, I have
assumed the following:

Extra Resolutions: 600x600, 1200x1200, 2400x1200.
4-level printing (HP CRet) with 2 cartridges (CMYK).
Max paper size: A4/Letter.

Dave Hill

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Re: PCL files.

[Dave H. <da...@mi...>]

Note for gimp-print readers: Eddie sent me some files from the
HP Web site. Now back to our normal programme....

Eddie,

As I suspected, there is nothing earth-shattering in the files
you sent me.

The gimp driver uses raster graphics mode only and there is not
much mention of anything to do with that. It doesn't mention
anything to do with CRet (4 level printing) in the 800 series,
or the contents of any of the more esoteric commands (like
"Configure Raster Data" or "Palette Configuration").

I know that Martin is still working with his driver for
ghostscript, as there are comments on his page about a
newer version coming along.

I will submit some changes to gimp-print that add support for
the resolutions that Deskjet 9xx's can do, but I can't really
test them!

Regards,
Dave Hill

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Colormanagement

[Karl H. K. <kh...@kh...>]

There was some discussion on this list some time ago about CMS.
I am looking into this for my scanner work. If somebody is
interested, I've a version of lcms (www.coloraid.de->lcms),
which was Windows software, running under Linux/i386. Marti,
the author helped a lot getting this to compile and run under
Linux. I've done a quick and dirty plugin for Gimp just to=20
get something to work with. So if anybody is interested in
e.g. doing the RGB->CMYK transformation based on ICC
profiles just let me know.

Karl Heinz
--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] 3.1.2

[Robert L K. <rl...@al...>]

I'd like to do a 3.1.2 this week (maybe even tomorrow, since my wife
will be busy).  I might try one more dither hack first, if I feel
really courageous :-)  Steve Miller says the GUI stuff won't be ready
before late this week at the earliest, and that's going to be a
radical enough change that it might be worthwhile putting something
out beforehand.  We have preliminary support for some more HP stuff in
there, and I finally got the Epson 440 printing 720 softweave (still
not the higher quality -- the weave code still has some limitations).

[Gimp-print-devel] [khk@khk.net: Colormanagement]

[Karl H. K. <kh...@kh...>]

I guess this message never made it to the list. It's now more
than five hours...


----- Forwarded message from Karl Heinz Kremer <kh...@kh...> -----

Date: Mon, 20 Mar 2000 17:07:02 -0500
From: Karl Heinz Kremer <kh...@kh...>
To: gim...@li...
Subject: Colormanagement
Mail-Followup-To: gim...@li...
X-Mailer: Mutt 1.0i

There was some discussion on this list some time ago about CMS.
I am looking into this for my scanner work. If somebody is
interested, I've a version of lcms (www.coloraid.de->lcms),
which was Windows software, running under Linux/i386. Marti,
the author helped a lot getting this to compile and run under
Linux. I've done a quick and dirty plugin for Gimp just to=20
get something to work with. So if anybody is interested in
e.g. doing the RGB->CMYK transformation based on ICC
profiles just let me know.

Karl Heinz
--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net



----- End forwarded message -----

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

Re: [Gimp-print-devel] dither_cmyk broken

[Robert L K. <rl...@al...>]

   Date: Mon, 20 Mar 2000 23:47:08 +0000
   From: Dave Hill <da...@mi...>

   The latest changes in print-dither.c (from 1.14 to 1.16) have
   apparently broken dither_cmyk when black is used (i.e. CMYK mode).

   It still works fine in CMY mode, but in CMYK mode the image
   "fades" towards the bottom right and the colours aren't right.

   Robert, if you still have the Tux logo I sent you, try printing
   to file using "Deskjet 500C/540C" (CMY) and then "Deskjet 550C/560C"
   (CMYK), then pcl-unprinting them.

OK, it should be fixed now.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] dither_cmyk broken

[Robert L K. <rl...@al...>]

   Date: Mon, 20 Mar 2000 23:47:08 +0000
   From: Dave Hill <da...@mi...>

   The latest changes in print-dither.c (from 1.14 to 1.16) have
   apparently broken dither_cmyk when black is used (i.e. CMYK mode).

   It still works fine in CMY mode, but in CMYK mode the image
   "fades" towards the bottom right and the colours aren't right.

   Robert, if you still have the Tux logo I sent you, try printing
   to file using "Deskjet 500C/540C" (CMY) and then "Deskjet 550C/560C"
   (CMYK), then pcl-unprinting them.

They both look wrong to me (the 540 looks worse).  However, it looks
just fine printed on my EX.

What settings are you using?

Re: [Gimp-print-devel] Epson Stylus 660

[Robert L K. <rl...@al...>]

   Date: Mon, 20 Mar 2000 19:07:01 +0100
   From: Thomas Tonino <tt...@bi...>

   It might be worthwhile to try the few matrices that are on my website (
   http://people.a2000.nl/ztonino/dither/files/64C for example) as the
   randomizing data in the FS process. It is bound to be less visible than
   true random noise. If the patent problems are too complicated for a
   production environment, I'm willing to spend a day or more on an
   "artistically created" equivalent. The good thing about void-and-cluster
   generated random data is that it is of higher frequency than normal
   random data: blue noise as opposed to white noise.

The current dither code isn't general enough to be able to handle
arbitrary matrices.  It's probably worth generalizing it some time.
Right now it uses an adaptive matrix (or what I call an adaptive
matrix, at any rate :-) ).

Re: [Gimp-print-devel] Epson Stylus 660

[Robert L K. <rl...@al...>]

   Date: Mon, 20 Mar 2000 17:37:39 +0100
   From: Hrafnkell Eiriksson <he...@kv...>

   I have just bought a Epson Stylus Color 660. I just installed
   v3.1.1 of the gimp-print plugin. I see that the Stylus 660
   is not listed in the setup for supported printers.

Try the 640 driver.

   Btw. I know that you guys are trying to improve the dithering code.
   I just did a quick search for articles on error diffusion and inkjet
   printing in the online article database at my university. I found
   an article called "Error diffusion with ink reduction for high
   quality and high resolution ink jet printing" by Joseph Shu at
   Epson Palo Alto Labs. Have you seen it? It appeared in the proceedings of
   IEEE International Conference on Image Processing 1995.

Thanks!  I haven't seen that.

   PS: Is the patent situation with dithering algorithms complicated?

I have no idea.  I've read in a number of places that people who
aren't patent lawyers should *not* attempt to do patent searches or
read patents (in the US, at any rate).  As best as I can retell, if
you've read a patent and you get asked to cease and desist, you are
assumed to be unable to determine if you're in violation or not, and
must assume that you are (only a patent lawyer is deemed competent to
determine if you've violated it).  If you haven't read it, things are
a bit different.  It was really bizarre.

I've heard from other sources, though, that people who aren't patent
lawyers who might get into patent disputes should not read patents.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton