gimp-print-devel

Re: [Gimp-print-devel] Black generation, continued

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

   Date: Mon, 22 May 2000 01:06:10 +0200
   From: Thomas Tonino <tt...@bi...>

   Robert L Krawitz wrote:

   > 1) The black is coming in too quickly on the 870, as you surmised.  I
   >    haven't tried the EX yet, but I suspect it would be even more
   >    noticeable.

   Wouldn't this be a matter of adjusting the lower and upper bounds for
   black?

It could be; k_lower and k_upper have changed effective meanings many
times now.

   While I'd rather have those corners smoothed. Any idea for a quick
   function? I'm thinking about scaling the beginning and end of the values
   to -1 and +1, and then doing 3*tk - tk*tk*tk as a transfer function.
   Makes a smooth curve and is not too slow.

It also needs long long arithmetic, which is significantly slower.

   > 2) The behavior at 720 dpi is significantly different -- there's much
   >    more black, and very dark regions look like they're not getting
   >    enough ink.

   I do not notice this with the 600, but that may be because I leave
   density at 1.

The density that you input is multiplied by the printer's density
setting (see printers.xml), which is about .6.

   In any case, I was happy to be able to use a lot of black if I wanted: I
   like to check pathological cases - they make me understand what goes
   wrong. But in this case, using a lot of black seemed to work fine.

The two issues with using a lot of black are:

1) Heavy black dots in areas not dark enough to mask them.

2) Insufficient total ink (if the black is at the expense of CMY) to
   fill everything in solidly (this varies with paper).

-- 
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] Black generation, continued

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> 1) The black is coming in too quickly on the 870, as you surmised.  I
>    haven't tried the EX yet, but I suspect it would be even more
>    noticeable.

Wouldn't this be a matter of adjusting the lower and upper bounds for
black? Mmmm... maybe we need a smoother start at the beginning of the
curve as well - maybe I should take tk to the power of 2, so we get a
smooth start anyway - but I'd like the elimination of the final bits of
color also to be smooth. Now the curve that generates bk is like:

       ____
      /
     /
____/

While I'd rather have those corners smoothed. Any idea for a quick
function? I'm thinking about scaling the beginning and end of the values
to -1 and +1, and then doing 3*tk - tk*tk*tk as a transfer function.
Makes a smooth curve and is not too slow.

> 2) The behavior at 720 dpi is significantly different -- there's much
>    more black, and very dark regions look like they're not getting
>    enough ink.

I do not notice this with the 600, but that may be because I leave
density at 1. Could be some problem with using 65536 versus d->density,
but I thought I had that right by now. In any case, previously the
driver would take away topo much CMY for every K part added: when using
more black than default, a grey wedge would show a light band where
black cut in - so I am a bit surpised that now you see this effect.

> 3) I think the ink reduction might be a bit too effective -- there
>    just isn't enough ink in dark solid colors.

I was thinking, on the way home, that the ink reduction could better
happen after we make up our optimal CMYK valye. We'd add the ink amount,
find how much we're over budget, and subtract half of that from CMY and
add to K. The budget value could probably be derived from the upper
bound for black. That would mean we'd remove the functionality from
where it is now and move it to the absolute end.

I think I have something to try tomorrow. Enough new ideas. Jean-Marc, I
had a quick glance at your code but do not see any difference in the way
you generate black (i.e. the part directly following  if (black !=
NULL)  in dither_cmyk. Is that correct?

In any case, I was happy to be able to use a lot of black if I wanted: I
like to check pathological cases - they make me understand what goes
wrong. But in this case, using a lot of black seemed to work fine.

I also hope the 257 x 257 matrix will be ready tomorrow. Curious what it
will bring...


Thomas

Re: [Gimp-print-devel] Black generation, continued

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

It does very nicely in very dark tones at 1440.  However, there are a
few things:

1) The black is coming in too quickly on the 870, as you surmised.  I
   haven't tried the EX yet, but I suspect it would be even more
   noticeable.

2) The behavior at 720 dpi is significantly different -- there's much
   more black, and very dark regions look like they're not getting
   enough ink.

3) I think the ink reduction might be a bit too effective -- there
   just isn't enough ink in dark solid colors.

Could you and Jean-Marc discuss this a bit more?  You both have some
very promising stuff, and maybe between you you can figure out how to
combine some of your ideas.

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Lauris K. <la...@ar...>]

On Sun, 21 May 2000, Robert L Krawitz wrote:

>    Well - at moment, to do advanced C based OO programming, most people use
>    Gtk+, thus creating implicit dependency in X libraries installed. But this
>    does not mean, that X has to be RUNNING.
> 
> MOST people?  Where I happen to work (a major system vendor), I
> haven't heard Gtk+ mentioned even once.

Lets not start language flaming here :) But I insist, that using OO
techniques is often good, and using any other (I do not any such, but
certainly there are) C toolkit involves lot more installing pain to user.
Fortunately commercial unixes are slowly starting to mimic Linux, so
sooner or later you can find Gtk+ included with your favourite unix
too. (Miguel and others are working like madmen, to make it happen sooner
:)

>    The one goal of Gnome is to provide good set of support libraries for
>    programming. At moment sending PS commands to filedescriptor does not
>    help people creating neither cute print previews (no alpha) nor export to
>    bitmaps (same reason). Rendering job in client-side is reasonable for
>    bitmap applications (GIMP), but huge overkill for all vector/text based
>    apps. And until some free PS renderer is created, using libart or similar
>    techinque, the best possible solution for these is certainly hybrid
>    system, like gnome-print is now. It lets you use any spooling and
>    rasterizing engine, while preserving client-side consisteness and
>    extensibility, which is lost with plain PostScript.
> 
> Wait a minute -- there IS a free Postscript renderer around.  It's
> called Ghostscript.  What am I missing here?

Unfortunately its quality is too poor for on-screen display or bitmap
rendering. Porting GS to libart is one possibility, of course. Plus
someone has to create alpha extensions to it.

Regards,
Lauris

Re: [Gimp-print-devel] Black generation, continued

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> I'm not too concerned about having more matrices; it does mean more
> space will be consumed (although we could use unsigned shorts to store
> the matrices), but if the quality improves enough, it's well worth
> it.

I commited a second matrix under print/Matgen. I am now generating a
257x257 matrix, but that will take a while. I'll commit that too,
including the new quickmatrix source including all used parameters.

I tried making a 73x73 matrix but that is just too self-correlated.
Produces interference patters if overlaid with itself.

> If you want to put it in, please do so.  If it elicits too many
> screams, somebody will just back it out.  That's the nice thing about
> source control.

OK. I cleaned it up a bit and added an ink reduction mechanism. It
basically does what it did before, with some modifications in scaling.
These modifications make it work well if the black limits are set lower.
I reflected this in print-escp2.c. Instead of 0.4 and 0.999 there are
now values of 0.25 and 0.6. This may be a bit much for six color
printers.

Added is functionality that can produce more black than before if there
is more than 100% ink coverage. This prevents the paper from being
soaked.

I can imagine adding something that cals will reduce some ink in full
colors by replacing some with black: good for printing on real plain
paper.

> Make sure it works well with colors.tif
> (http://www.tiac.net/users/rlk/colors.tif).  That's a pretty good test
> for finding discontinuous behavior.

That works well.

> As for black level, it's very important that it start at zero and
> smoothly increase for the variable dot size printers, to allow a range
> that uses small black dots.

I wouldn't dare doing otherwise: discontinuities in curves will produce
discontinutities in output. No way one can compensate for that.

I hope the black values I set in print-escp2.c are good for 6 color
printers as well, but my feeling is that this section needs to be
expanded:

- 6 color printers get a higher threshold for beginning to use black
- variable dot size printers get a lower threshold for beginning to use
black
- cheap paper maxes out on black early
- coated paper takes more ink so the curve can be smoother

The last 2 are reflected in the current print-escp2.c.

I have confidence now that the bblack separation is useable with a wide
variation of thresholds. I tried 0.1 and 0.2 as thresholds. Grainy
result, but generally okay. 0.25 and 0.6 seem to be fine for my printer:
green midtones are mostly hidden by the black, and there is no
noticeable extra grain.



Thomas

Re: [Gimp-print-devel] Epson 870 shot 2 (sorry)

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

   Date: Sun, 21 May 2000 01:25:40 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   Again, I've put my files (print.h, print-escp2.c and print-dither.c) at
   "ftp://perse.saclay.cea.fr/pub/incoming/verbavatz" for testing and comments.
   They're based on the version of May 18th of gimp-print. Robert, I knew you
   couldn't help playing with dithering but I understand that :)

It appears to me that you've generalized the range stuff somewhat, so
a given value can be covered by multiple ranges.  Good.

I like it (at 1440x720 highest quality).  There are a few issues,
though:

1) There's still the yellow-green cast.

2) I think that the value you've assigned the light colors (lc and lm)
is too high.  This results in their receiving too much credit for ink
printed, which leads to an overly sharp transition between light and
dark.  I think that this is the source of the yellow cast, actually;
in midtone areas, not enough dark magenta and cyan is used, so the
yellow is too prominent.  My last try suggested that .22 was a good
ratio.

   I've compared the rendering with the current repository (from May 19th) and:

   - it looks a lot better to me as far as grain and dithering is concerned.

The problem I'm seeing there is that there are a lot of regions of
fine horizontal lines, like an ordered dither.  I haven't tracked down
where that's coming from.

   - the density is much lower. This is because my color values are
   quite different. I've tried to work out each of them separately so
   that they would give the same output (on my printer). I think the
   current repository yields a much lower gamma because values are
   decreasing (from darkest to lightest) much faster than what I've
   done. I believe we should just set a higher density for this
   printer instead.

Density and brightness/gamma are two different things.

   - I have, from what I've seen, a better balance between light and
   dark inks, at least at higher qualities, which should increase the
   lifetime of cartridges.

That's always good.

-- 
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] Epson 870 shot 2 (sorry)

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

   Date: Sun, 21 May 2000 01:25:40 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   Again, I've put my files (print.h, print-escp2.c and print-dither.c) at
   "ftp://perse.saclay.cea.fr/pub/incoming/verbavatz" for testing and comments.
   They're based on the version of May 18th of gimp-print. Robert, I knew you
   couldn't help playing with dithering but I understand that :)

Could you create a directory in CVS named print/jmv or the like, and
check your files in there?  Thanks.

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

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

   Date: Sun, 21 May 2000 03:17:47 +0200 (CEST)
   From: Lauris Kaplinski <la...@ar...>

   Mos of which are programs. gnome-libs package from Red Hat 6.1 is less
   than megabyte. To /usr/lib it installs less than 1.8MB of files.
   Aside standard stuff (X etc.) it requires esd, gnome-audio, xpm, jpeg and
   png libraries. Not very much.

It requires SOUND support?

   Well - at moment, to do advanced C based OO programming, most people use
   Gtk+, thus creating implicit dependency in X libraries installed. But this
   does not mean, that X has to be RUNNING.

MOST people?  Where I happen to work (a major system vendor), I
haven't heard Gtk+ mentioned even once.

   The one goal of Gnome is to provide good set of support libraries for
   programming. At moment sending PS commands to filedescriptor does not
   help people creating neither cute print previews (no alpha) nor export to
   bitmaps (same reason). Rendering job in client-side is reasonable for
   bitmap applications (GIMP), but huge overkill for all vector/text based
   apps. And until some free PS renderer is created, using libart or similar
   techinque, the best possible solution for these is certainly hybrid
   system, like gnome-print is now. It lets you use any spooling and
   rasterizing engine, while preserving client-side consisteness and
   extensibility, which is lost with plain PostScript.

Wait a minute -- there IS a free Postscript renderer around.  It's
called Ghostscript.  What am I missing here?

[Gimp-print-devel] Epson 870 shot 2 (sorry)

[Jean-Marc V. <ver...@if...>]

Please accept all my apologies for the "Mail failed, returning to sender"
message that I forwarded to this list by mistake. It's late and I must be
tired.
This is what the message was supposed to read:

I've been working on the epson 870 and this is my second shot. I think it's
much better than the first one.

Again, I've put my files (print.h, print-escp2.c and print-dither.c) at
"ftp://perse.saclay.cea.fr/pub/incoming/verbavatz" for testing and comments.
They're based on the version of May 18th of gimp-print. Robert, I knew you
couldn't help playing with dithering but I understand that :)

Again this will only work for epson 870s and the like.

In this version, I've fixed a few problems, worked on all of the inks again and
implemented a variable threshold for the inks as previously discussed.

I've tried colors.tif this time and it looks good to me.

I've compared the rendering with the current repository (from May 19th) and:

- it looks a lot better to me as far as grain and dithering is concerned.

- the density is much lower. This is because my color values are quite
different. I've tried to work out each of them separately so that they would
give the same output (on my printer). I think the current repository yields a
much lower gamma because values are decreasing (from darkest to lightest) much
faster than what I've done. I believe we should just set a higher density for
this printer instead.

- I've also tried printing on my old Epson Photo 700 today and for the exact
same values (where applicable) the density was much higher. Same conclusion as
above as far as I'm concerned.

- I have, from what I've seen, a better balance between light and dark inks, at
least at higher qualities, which should increase the lifetime of cartridges.

- Black (k) values may need some additional work.

Thanks for giving this another try,

-- 
--
Jean-Marc Verbavatz		<ver...@if...>
5, rue La Fontaine		"http://perso.cybercable.fr/verbavat"
F-75016 Paris

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Lauris K. <la...@ar...>]

On Fri, 19 May 2000, Robert L Krawitz wrote:

>    Date: Sat, 20 May 2000 03:06:56 +0200 (CEST)
>    From: Lauris Kaplinski <la...@ar...>
> 
>    There is no such thing as GNOME dependency (aside packages :).
> 
> Which you really shouldn't brush off like that.  It's quite a lot of
> stuff.  My /opt/gnome (October) is 80 MB, and what looks like about 50
> packages.

Mos of which are programs. gnome-libs package from Red Hat 6.1 is less
than megabyte. To /usr/lib it installs less than 1.8MB of files.
Aside standard stuff (X etc.) it requires esd, gnome-audio, xpm, jpeg and
png libraries. Not very much.

Also, for much users it is much easier to have one big dependency
(libgnome) than many small ones (From where can you find separate libart
SUSE package, for example?).

Not having GNOME is all about not having desktop components installed
(panel, filemanager etc.)

> 								  
> 								  There are
>    dependencies to several different free libraries, which happen to be
>    distributed as a part of GNOME. And some libraries has every program to
>    use, if it does not want to reimplement all things under the sun...
> 
> Fine, and what do THOSE libraries depend on?  glib is actually
> reasonably self contained; most of the others depend on a lot of other
> stuff.  Now we start to get into DLL hell.
> 
>    Once gnome-print stabilizes enough, it would be meaningful to
>    separate it into GUI and backend parts. GUI part needs and will
>    always be needing libgnomeui for print-preview canvas, dialogs etc.
>    Non-gui base requirements are only Gtk+ (object system) and libart
>    (drawing primitives). Not very much, I think...
> 
> There's nothing wrong with the GUI stuff (and the printing API for
> GNOME programs) requiring the GNOME libraries.  That's completely
> appropriate.  It's the back end stuff that really needs to be done
> completely independently of any UI toolkit, desktop, etc.
> 
>    Still I think that in near future libgnomeui is installed in most
>    computers, so this is no-issue.
> 
> Sorry, I don't buy it.  KDE users won't do it, nor will Motif users,
> nor will CDE users.  Nor, for that matter, will servers.  Servers
> won't even have X installed on them.  If they need to be running X in
> order to handle printing, then we're just implementing Windows all
> over again, where the GUI permeates everything (and destabilizes and
> bloats it).  The back end printing system *had better* be completely
> independent of any particular UI choices (or lack thereof).

Well - at moment, to do advanced C based OO programming, most people use
Gtk+, thus creating implicit dependency in X libraries installed. But this
does not mean, that X has to be RUNNING.
Hopefully Gtk+ type system will be moved to glib - and similarly probably
some parts of gnome libs will be done X agnostic. But until then I can see
nothing wrong writing server programs with Gtk+.

> It bothers me that a lot of the GNOME stuff seems to assume that GNOME
> will be universal, and that requiring a lot of the GNOME subsystems to
> be installed is perfectly OK.  That isn't how it works in the real
> world.  If you want to do a generic UNIX printing facility, you need
> to completely give up on the idea of GNOME being part of it.

No. We do not assume everyone running panel etc. But is is completely
reasonable to use the best free renderer - libart - for rasterizing, and
the best display engine - GnomeCanvas - for print previews. You can have
both, without other Gnome, but usually it is much simpler to have full
libgnomeui package installed, instead of figuring out, how to set these
libraries up separately.

> I'm going to suggest -- pro forma, at least -- that gnome-print
> concentrate on providing a seamless UI and a good printing API for all
> GNOME applications.  The caanvas idea sounds great for that purpose --
> it provides an abstract imaging model that any GNOME-enabled
> application can use to render for any device.  Where I think you're
> overreaching is in going after the back end.

The one goal of Gnome is to provide good set of support libraries for
programming. At moment sending PS commands to filedescriptor does not
help people creating neither cute print previews (no alpha) nor export to
bitmaps (same reason). Rendering job in client-side is reasonable for
bitmap applications (GIMP), but huge overkill for all vector/text based
apps. And until some free PS renderer is created, using libart or similar
techinque, the best possible solution for these is certainly hybrid
system, like gnome-print is now. It lets you use any spooling and
rasterizing engine, while preserving client-side consisteness and
extensibility, which is lost with plain PostScript.

Regards,
Lauris

> 
> -- 
> 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] mail failed, returning to sender

[Jean-Marc V. <ver...@if...>]

|------------------------- Failed addresses follow: ---------------------|
 <gim...@so...> ... transport inet_zone_bind_smtp: 501 <jmv@accueil>... Sender domain must exist
|------------------------- Message text follows: ------------------------|
Received: from rabbit.verbavatz.fr  by accueil
	via smail with smtp (Smail-3.2 1996-Jul-4 #8)
	id <m12...@ac...>
	; Sun, 21 May 2000 03:01:26 +0200 (CEST)
Received: by accueil (Smail3.2)
	id m12tK8T-000RB5C; Sun, 21 May 2000 03:02:29 +0200 (CEST)
From: "Jean-Marc Verbavatz" <jm...@ra...>
Message-Id: <100...@ra...>
Date: Sun, 21 May 2000 01:02:29 +0000
Operating-System: Linux 2.0
X-Face: KXe+dZ=w;^w~5[I5Uu=<nq6jmY~rp}%$>[H=0Ney\xxHw0$@|*>L|+{_l`}HS)@QxM-+hvS\V!n#Zne&?/Q@>U&CG(YKnBP-c9siKv^I2&]c[%]+m,jC&|O]xN*$Iu.x7r>^41'tyu6,Ges~<nVH/#Y2U)#Ej]Hoq6gKI43])8Y#Y#5*'2+TM"I`XXt7i<k
X-Mailer: Z-Mail (3.2.1 24feb96 Caldera)
To: gim...@so...
Subject: Epson 870 shot 2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

I've been working on the epson 870 and this is my second shot. I think it's
much better than the first one.

Again, I've put my files (print.h, print-escp2.c and print-dither.c) at
"ftp://perse.saclay.cea.fr/pub/incoming/verbavatz" for testing and comments.
They're based on the version of May 18th of gimp-print. Robert, I knew you
couldn't help playing with dithering but I understand that :)

Again this will only work for epson 870s and the like.

In this version, I've fixed a few problems, worked on all of the inks again and
implemented a variable threshold for the inks as previously discussed.

I've tried colors.tif this time and it looks good to me.

I've compared the rendering with the current repository (from May 19th) and:

- it looks a lot better to me as far as grain and dithering is concerned.

- the density is much lower. This is because my color values are quite
different. I've tried to work out each of them separately so that they would
give the same output (on my printer). I think the current repository yields a
much lower gamma because values are decreasing (from darkest to lightest) much
faster than what I've done. I believe we should just set a higher density for
this printer instead.

- I've also tried printing on my old Epson Photo 700 today and for the exact
same values (where applicable) the density was much higher. Same conclusion as
above as far as I'm concerned.

- I have, from what I've seen, a better balance between light and dark inks, at
least at higher qualities, which should increase the lifetime of cartridges.

- Black (k) values may need some additional work.

Thanks for giving this another try,



-- 
--
Jean-Marc Verbavatz		<ver...@if...>
5, rue La Fontaine		"http://perso.cybercable.fr/verbavat"
F-75016 Paris

Re: [Gimp-print-devel] Black generation, continued

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

   Date: Sat, 20 May 2000 18:11:57 +0200
   From: Thomas Tonino <tt...@bi...>

   > It isn't enough.  Not only do we need matrices to dither the output
   > dots, we also need to dither different dot sizes and colors.  That
   > matrix *must* be just as good as the others, and it *must* be
   > uncorrelated.

   If it must be really uncorrelated, I guess the only thing to do is to
   generate a number of them. But I feel that the only correlation problem
   we might run into is the initial few points of the matrix against the
   same initial points. If these are displaced for every use, the rest will
   be practically uncorrelated.

The requirements for the dot selection matrices are different from the
ones that decide whether to print ink.  Extremely even sparse behavior
is less of an issue; complete lack of correlation with the matrix that
governs whether to print at all is crucial.  I'd actually prefer that
a matrix of different size be used for that purpose, although I'm not
certain that that's critical.  I'm afraid that simply shifting the
matrix will generate low-frequency patterning.

I'm not too concerned about having more matrices; it does mean more
space will be consumed (although we could use unsigned shorts to store
the matrices), but if the quality improves enough, it's well worth
it.

   In any case, the 'problem' was my stupidity. In any case, I like to use
   the autocorrelation properties of the matrix for very low density. It
   makes sure that a very light grey gets printed with C and M dots far
   apart. As density increases dots are filled in more or less at random
   and correlation between different sections of the matrix gets extremely
   low.

What you want in that case is actually negative correlation.

   I hope the second independent matrix works out for the light vs dark ink
   decisions. Let me know how you fare: I'm really happy with the extra
   black I put in, so seeing it appear in cvs would be great - but I don't
   feel like doing that myself yet: it is a quick hack, I haven't tested
   with other printers, etc.

If you want to put it in, please do so.  If it elicits too many
screams, somebody will just back it out.  That's the nice thing about
source control.

   I think I oversimplified that bit of code by taking out those ifs to
   check inputs and instead checking results. How does it work on the EX
   anyway? I see now that the driver really reacts to the black limits that
   are set and that a greay wedge is nicely monotonous.

Make sure it works well with colors.tif
(http://www.tiac.net/users/rlk/colors.tif).  That's a pretty good test
for finding discontinuous behavior.

As for black level, it's very important that it start at zero and
smoothly increase for the variable dot size printers, to allow a range
that uses small black dots.  If you really want a lot of black to hit
fast, you can handle that by having the density argument to
print_color start at zero and increase smoothly (that's what's used to
decide what tone to print).

-- 
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] packaging or: trying to break bogus MS patents

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

   Date: Sat, 20 May 2000 22:32:29 +0200
   From: Torsten Landschoff <to...@de...>

   I guess using the AFPL for gimp-print is out of question. OTOH you could 
   distribute the driver for ghostscript under a dual license so that the user
   can select between the AFPL and GPL for that driver. 

   Or even use the LGPL for gimp-print. That would probably suffice to allow
   linking to gs. Otherwise we will just have the gimp-print driver in the 
   gnu gs package and included in the gs-aladdin source but disabled by 
   default. A user could still compile a custom package with gimp-print for 
   local use.

There's a potential problem with that; we're investigating some code
by Raph Levien that's covered by a patent that allows free use with
GPL code.  So if we use that code (and it supposedly does
spectacularly well on the printers to which it's currently
applicable), we'd have a problem (or we'd need special dispensation
from Raph).

-- 
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] packaging or: trying to break bogus MS patents

[<sh...@al...>]

> Sorry, I am very late in this discussion but to be honest I did not 
> quite understand what was expected from me...

No more than you wish to contribute.  Gimp-print is still very much in
development.  Getting it into potato is out of the question.  It would be
a nice addition to woody, though.

> Interesting. May I ask what the gimp-print plugin provides to the 
> application and to the user?

The name "gimp-print" is really misleading at this time.  It began as
a plug-in for the Gimp and it still bears that name, but, in general it is
a high quality suite of printer drivers which includes support for printers
made by Epson, HP, and Canon at this time.  It includes support for printers
which contain 6 or 7 inks and are capable of multiple ink droplet sizes.
No other gs drivers can do that at this time, AFAIK.

It is currently usable in two forms, either as a plug-in for the gimp, which
will allow the Gimp to print directly to the printer bypassing ghostscript
or other printer filters, or as a ghost script driver.  (The ghostscript
driver currently supports only Epson printers at this time, although there's
no real reason for that other than lack of manpower.)

> While the context is not clear to me I can explain why I have such a big
> .diff.gz. The reason is quite simple actually - the Debian gs package 
> includes a lot of contributed drivers as well as kanji support. This sums
> up to about 2.7MB unpacked...

Yes, I understand that now.

> So gimp-print needs a driver in ghostscript? I don't see the problem, 
> it's just another driver for me to add to the Debian package. Or am I 
> missing something?

No, you're not missing anything.  In fact, I have a script in CVS now which
will apt-get source gs and libjpeg, apply a patch, to the source, and then
build a new gs package with the driver installed.  If you would like to
include this patch in the official Debian woody release of gs, that would be
great.

Can you take a look at what I've done?  The project website is available
at http://gimp-print.sourceforge.net and instructions for accessing the
CVS tree are there.  There's a script called make-deb.sh which does
everything.

> I guess using the AFPL for gimp-print is out of question. OTOH you could 
> distribute the driver for ghostscript under a dual license so that the user
> can select between the AFPL and GPL for that driver. 

As far as I know Robert is committed to remaining GPL.  That's my preference
as well, but, I'll defer to his judgement on this point.  I think we'll need
to be in Gnu Ghostscript and Gnu Ghostscript only.

Eric

Re: [Gimp-print-devel] packaging or: trying to break bogus MS patents

[Torsten L. <to...@de...>]

Hi *, 

Sorry, I am very late in this discussion but to be honest I did not 
quite understand what was expected from me...

On Sat, May 06, 2000 at 10:30:42AM -0400, sh...@su... wrote:
> 
> (Quick review for Ben and Torsten: We're discussing how to package
> Gimp's print plug-in for Debian.  Gimp-print is trying to separate
> itself from the Gimp and become a generalized printer driver package.
> It currently works from within Ghostscript as well as from the Gimp.)

Interesting. May I ask what the gimp-print plugin provides to the 
application and to the user?

> > I thought I put everything in there (except a 1 MB
> > gs-aladdin_5.50-8.diff file -- should that be in there?)

While the context is not clear to me I can explain why I have such a big
.diff.gz. The reason is quite simple actually - the Debian gs package 
includes a lot of contributed drivers as well as kanji support. This sums
up to about 2.7MB unpacked...

The next package will use doogie's build system to get rid of this large
diff.gz. I hope to finish the package this weekend.

> Hmm.  Possibly, but I'm not sure what's in it.  I'm surprised it's that
> long.  Can you put a copy of it somewhere where I can grab it and then
> I'll take a look at it and decide if it needs to be included or not.
> It may be better to include a script which can generate such a file,
> but I'd still like to get a copy of it to see what he's done.

See above. I really dislike the current state of the gs package. As an aside
the next release will include the libjpeg sources because currently the 
autobuilders can't handle building gs without manual interaction (I think 
there is a feature for this which was added only for gs :(

The right solution to this problem is to separate the core of gs from the 
printer drivers and have a small gs package along with a number of 
gs-driver-xxx packages which are dynamically loaded.

I want to work for the implementation of that but it is a lot of work and
I will not probably start it before I have a weekend to spend.

> I think gimp-print will need to be removed from the official debian
> gimp package and separated into its own package.  This is not so hard
> to do.

In fact a small modification to the gimp package would do it for now. Just
move the gimp-print parts away and create another package from it.

> Unfortunately, ghostscript is not as easy to handle.  Since there is no
> plug-in architecture, and the gimp-print driver must be actually compiled
> into ghostscript, I think the only way to optionally provide gimp-print
> at this time would be to have alternative ghostscript packages.

So gimp-print needs a driver in ghostscript? I don't see the problem, 
it's just another driver for me to add to the Debian package. Or am I 
missing something?

> There are also legal issues involved with making a gs-aladdin-gimp-print
> package.  I don't think such a beast could be legally distributed.
> Using gnu ghostscript should work, though, and has no licensing problems.
> Anyone care to comment on that?

I guess using the AFPL for gimp-print is out of question. OTOH you could 
distribute the driver for ghostscript under a dual license so that the user
can select between the AFPL and GPL for that driver. 

Or even use the LGPL for gimp-print. That would probably suffice to allow
linking to gs. Otherwise we will just have the gimp-print driver in the 
gnu gs package and included in the gs-aladdin source but disabled by 
default. A user could still compile a custom package with gimp-print for 
local use.

cu
    Torsten

-- 
Torsten Landschoff           Bluehorn@IRC               <to...@de...>
           Debian Developer and Quality Assurance Committee Member

Re: [Gimp-print-devel] Black generation, continued

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> You really want to use an appropriate set of if's around what's
> below.  There's no sense in performing the extra multiply and divide
> when you know you're going to throw away the result, and it also leads
> to the risk of range problems.

Hmm... divides may be a problem, but multiplies on modern processors are
pretty fast. Mispredicted branches can be slow, however.

By the way, I'm pretty sure GCC is clever enough to replace a divide by
a shift if that's faster. Also, I think it is better to leave
optimizations to the last: that allows you to use different loops for
different dithers. The code will be larger, but the loops smaller: hence
faster execution.

> It isn't enough.  Not only do we need matrices to dither the output
> dots, we also need to dither different dot sizes and colors.  That
> matrix *must* be just as good as the others, and it *must* be
> uncorrelated.

If it must be really uncorrelated, I guess the only thing to do is to
generate a number of them. But I feel that the only correlation problem
we might run into is the initial few points of the matrix against the
same initial points. If these are displaced for every use, the rest will
be practically uncorrelated.

The matrix to be re-used 8 times was not a success. I'n now generating
another 199 sized matrix with different initial points. As there is a
fair amount of randomness in the matrix generation (and random actually
gets initialized with a time() call...) it should be uncorrelated.

Both matrices can be used 4 times, by shifting 100 pixels X and/or Y,
and both should be of equal quality.

>  I have a fix in hand that improves output on my EX, and
> in some places it improves output on the 870.  Unfortunately, in other
> places it also makes the 870 output worse, because I don't have a good
> enough dither there.
> 
>    I guess I first have to find out what broke the use of the first matrix.
>    So far for organized working on my side.
> 
> Don't worry about it.

In any case, the 'problem' was my stupidity. In any case, I like to use
the autocorrelation properties of the matrix for very low density. It
makes sure that a very light grey gets printed with C and M dots far
apart. As density increases dots are filled in more or less at random
and correlation between different sections of the matrix gets extremely
low.

I hope the second independent matrix works out for the light vs dark ink
decisions. Let me know how you fare: I'm really happy with the extra
black I put in, so seeing it appear in cvs would be great - but I don't
feel like doing that myself yet: it is a quick hack, I haven't tested
with other printers, etc.

I do think the old code had too much possibilities to reduce printing of
black. I achieved good results with the code I posted, which basically
does:

- Find what black is represented in the color that we want to print.
- See where that falls between black_lower and black_upper
- Calculate accordingly what percentage of the black value to print as
black
- Subtract that black from the individual colors.

I think I oversimplified that bit of code by taking out those ifs to
check inputs and instead checking results. How does it work on the EX
anyway? I see now that the driver really reacts to the black limits that
are set and that a greay wedge is nicely monotonous.


Thomas

Re: [Gimp-print-devel] Black generation, continued

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

   Date: Sat, 20 May 2000 12:09:41 +0200
   From: Thomas Tonino <tt...@bi...>

   >    I reinstated the old kdarkness generation:
   > 
   > I think that that's the wrong approach.  I'm trying to remember
   > exactly why I got rid of it, but it behaved very strangely.  Maybe we
   > need that to be configurable.

   I decided to take out everything I didn't fully understand, and did a
   little cleaning up. It reacts properly now to set_black_upper and
   -_lower and colors look good. It also seems faster. This is what is
   left:

	 oc = c;
	 om = m;
	 oy = y;
	 k = MIN(c, MIN(m, y));

	 if (black != NULL)
	   {
	     ok = k;
	     ak = k;
	     ub = d->k_upper;	/* Upper bound *
	     lb = d->k_lower;	/* Lower bound */
	     rb = ub - lb;	/* Range */

You really want to use an appropriate set of if's around what's
below.  There's no sense in performing the extra multiply and divide
when you know you're going to throw away the result, and it also leads
to the risk of range problems.

	     bk = (ok - lb) * d->density / (ub - lb);
	     if ( bk < 0)
	       bk = 0;
	     if ( bk > d->density )
	       bk = d->density;
	     k = bk;
		   y = 0;
	       }

   I'm doubting what to do with the matrices. On one hand, a matrix that
   performs very well when shifted halfway right and halfway down sounds
   like the way to go. This allows the two darkest colors to mix well.
   Other stuff can be mixed in in less optimal positions.

It isn't enough.  Not only do we need matrices to dither the output
dots, we also need to dither different dot sizes and colors.  That
matrix *must* be just as good as the others, and it *must* be
uncorrelated.  I have a fix in hand that improves output on my EX, and
in some places it improves output on the 870.  Unfortunately, in other
places it also makes the 870 output worse, because I don't have a good
enough dither there.

   I guess I first have to find out what broke the use of the first matrix.
   So far for organized working on my side.

Don't worry about it.  If you knew how many times I've busted the
dither code myself, you'd want to toss me off the project.  In fact,
the fix that I'm going to check in (and it IS, overall, a fix) is only
the latest flip-flop in that regard (what value to subtract from the
error when printing a dot that may be one of two strengths).

-- 
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] Ghostscript driver

[Michael S. <mi...@ea...>]

Robert L Krawitz wrote:
> ...
> Mike probably has much better ideas than this.  They probably all
> involve using CUPS for this purpose.  Either CUPS or PDQ would help
> out here on the front end.  The issue is reliably passing arguments
> to Ghostscript.
> ...

Send PS commands to set the options:

    <</HWResolution [x y]>>setpagedevice

etc.  Anything you set with -d, -s, -r, or -g on the command-line can
be set in PS code.

I should also mention that this allows you to use PPD files with the
print plug-in and then print using Ghostscript via CUPS, LPD, or PDQ.

(obviously I'm all for using CUPS, but PPDs and Ghostscript supports
 *any* printing environment)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print(fwd)

[Michael S. <mi...@ea...>]

Lauris Kaplinski wrote:
> ...
> Once gnome-print stabilizes enough, it would be meaningful to
> separate it into GUI and backend parts. GUI part needs and will

Um, so you'll provide some sort of command-line utility to print
files, and filter stuff, and handle options?  Sounds an awful lot
like you want a printing system then...

> ...
> Still I think that in near future libgnomeui is installed in most
> computers, so this is no-issue.

Okay...  Personally, I think that *might* be the case for Linux and
*BSD, but not for the commercial UNIX's for sure.  And gee, which
version will they ship, and how many people do you know that still
run Red Hat 5.x or some other old release and won't "upgrade"?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Michael S. <mi...@ea...>]

Miguel de Icaza wrote:
> ...
> I think you are pre-drowning on a glass of water.  Lets tackle
> problems as they arrive instead of giving up a priory because of an
> --honestly-- rather obscure setup that I can not even figure why it
> even matters.

Um, it's not that obscure and we have a LOT of customers using this
specific setup for their networks, specifically a Linux print/file
server for their Windoze clients.

Printing costs money.  Therefore, businesses, colleges, the military,
etc. want to track who is printing, what they are printing, etc.
Printing raw data makes this task nearly impossible, and like I say
below doesn't solve the printing problem for non-GNOME apps.

> > As for scalability, adding DSOs doesn't mean your solution is
> > scalable.  How many DSOs are required to implement N drivers?  N
> > DSOs?  And what about non-GNOME applications?  What do *those*
> > applications do for printing?!?
> 
> You lost me with the acronym.  I cant follow this at all.

N = a number
DSO = dynamic shared object
DSOs = dynamic shared objects
GNOME = you know what it means

How many DSOs (drivers) would you need to support sll of the
popular printers?  If you have N printers, do you need N DSOs?
How does GNOME-print discover printers, how does it discover
drivers?

Scalability means that you can expand the software to handle
larger tasks.  The internal drivers in GNOME-print fail at
this because:

    1. Drivers for network printers (served by other system)
       are not automatically available and/or configured, so
       GNOME-print does not scale to network environments.
    2. The drivers are only usable from GNOME applications,
       so GNOME-print cannot scale to support all printing
       under UNIX.

#1 also leads to problems with clients using the current version
or configuration of a printer driver, something that had been a
major thorn in our side with our customers until we came up with
CUPS.

Understand - I'm not trying to be mean-hearted.  I've just been
doing UNIX printing stuff for 7 years and printer drivers for a lot
longer.  Printing from applications is just one small problem in the
overall picture, and we need to address the whole picture if Linux
is to become a mainstream OS (with printer vendors doing Linux
drivers, etc.)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com

Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Michael S. <mi...@ea...>]

Miguel de Icaza wrote:
> ...
> The "dump to ghostscript, process, send to printer" solution is
> exactly what I believe to be fully broken for Unix to succeed on the
> desktop.  We have the infrastructure now to do things right, and I
> want to do this.

What's broken is LPD, and the sooner we eliminate LPD from the scene
the better.

> ...
> It does not matter.  Just specify that your band is the size of the
> page.  Problem solved.

Um, problem *not* solved.

Do some math: 8.5x11x1440x720x3 (assuming 24-bit RGB at device
resolution) = 85MB for a single page of graphics if you RIP the
entire bitmap in memory.  Double that for a tabloid size printer,
and forget about it if you hook up a large-format plotter (E size
= 1.4GB)

That said, as long as the bands are generated from top to bottom
and there is some sort of interface to indicate the beginning and
end of a page then any soft-weaved driver can work with a banded
RIP (like GS 5.50)

> ...
> I do not follow this, but it is ok.

See "http://www.cups.org"; in short, CUPS replaces the LPD printing
system with an IPP-based printing system.  Among other things, CUPS
provides applications with access to printer information (PPD files
primarily, but also current status, etc.) through IPP and HTTP, and
provides the framework for modern printer drivers under UNIX.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

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

On Fri, May 19, 2000 at 07:06:17PM -0400, Miguel de Icaza wrote:
> > "Corporate" users want accounting, security, quotas, encryption, etc.
> > Sending raw print data to the printing system prevents that
> > functionality from being realized, making wider acceptance of GNOME,
> > Linux, etc. more difficult.
>=20
> I think you are pre-drowning on a glass of water.  Lets tackle
> problems as they arrive instead of giving up a priory because of an
> --honestly-- rather obscure setup that I can not even figure why it
> even matters.

This does matter if you design a solution that is scalable. We may
be able to come up with the perfect solution for the desktop but
in doing so burn all bridges to a system than can be used on the
desktop and a server environment.=20

I'm working with high volume printing systems now for ten years
and believe me, these things are important.

We tan tackle implementation problems as they arrive, but design
decisions should be made way upfront in the process. We want a=20
solution that in theory should scale from a entry level ink-jet
to a high volume printer to an imagesetter.=20

Karl Heinz

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

Re: [Gimp-print-devel] Black generation, continued

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> How's the new matrix coming along.  If we're going to use any kind of
> ordered dither, we have to solve the autocorrelation problem.
> Remember that we have to solve it for variable dot size/color, too.

The new matrix was a disaster. That may be because of lack of randomness
First, it seems mostly a problem in areas with very low dot density. As
soon as something like 10 dots from the matrix are printed the positions
of these are essentially random. Still, I broke something in my code
that makes very low densities go bad now: maybe I left out an addition
that I had there before.

>    I reinstated the old kdarkness generation:
> 
> I think that that's the wrong approach.  I'm trying to remember
> exactly why I got rid of it, but it behaved very strangely.  Maybe we
> need that to be configurable.

I decided to take out everything I didn't fully understand, and did a
little cleaning up. It reacts properly now to set_black_upper and
-_lower and colors look good. It also seems faster. This is what is
left:

      oc = c;
      om = m;
      oy = y;
      k = MIN(c, MIN(m, y));

      if (black != NULL)
	{
	  ok = k;
	  ak = k;
	  ub = d->k_upper;	/* Upper bound *
          lb = d->k_lower;	/* Lower bound */
          rb = ub - lb;	/* Range */

          bk = (ok - lb) * d->density / (ub - lb);
          if ( bk < 0)
            bk = 0;
          if ( bk > d->density )
            bk = d->density;
          k = bk;
	 
	  if (bk > 0)
	    {
// Divide by 128 should really be by 64 and d->k_clevel etc should be
adjusted instead
	      bk = bk / 128;
	      c -= (d->k_clevel * bk);
	      m -= (d->k_mlevel * bk);
	      y -= (d->k_ylevel * bk);
	      if (c < 0)
		c = 0;
	      if (m < 0)
		m = 0;
	      if (y < 0)
		y = 0;
	    }

I'm doubting what to do with the matrices. On one hand, a matrix that
performs very well when shifted halfway right and halfway down sounds
like the way to go. This allows the two darkest colors to mix well.
Other stuff can be mixed in in less optimal positions.

I guess I first have to find out what broke the use of the first matrix.
So far for organized working on my side.


Thomas

Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Hrafnkell E. <he...@kv...>]

Hi

On Fri, May 19, 2000 at 09:30:45PM -0400, Robert L Krawitz wrote:
> There's nothing wrong with the GUI stuff (and the printing API for
> GNOME programs) requiring the GNOME libraries.  That's completely
> appropriate.  It's the back end stuff that really needs to be done
> completely independently of any UI toolkit, desktop, etc.

Actually I do not see any problem at all. Create each printer
driver as a shared library that accepts a pixmap as input and
outputs the printing commands. Nobody will ofcourse let such a
shared lib depend on libgnomeui or Qt or any UI lib.
Then any printing subsystem can have a good lowlevel print driver
be it the super-duper-mega-distributed-printing-system that solves
all problems in the world, ghostscript, cups or gnome-print or anything.
If I want to place the drivers at a system level I do that and if
the Gnome guys want to place the print drivers into application space
they do that. The interface of a printer driver should not depend
on whether you place it above or beneeth the transport layer of the
printing system.
I think this list (gimp-print) should concentrate on creating one such lowlevel
driver (it seems that you're good doing that!). I suggest we move
forward to discuss a common API for such drivers/shared libs.
I have looked at the interface for CUPS drivers and find it simple and
clean. That might be a starting point.

Thanks
 Hrafnkell
-- 
//-----------------------//-------------------------------------------------
//  Hrafnkell Eiriksson  // 
//  he...@kv...        // 
//  TF3HR                //  "Blessed are they who go around in circles,
//                       //   for they shall be known as Wheels"        

Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

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

   From: Miguel de Icaza <mi...@he...>
   Date: 19 May 2000 19:02:47 -0400

   > I recommend that you read the recent list archives.  Despite the name,
   > gimp-print is not solely used for the Gimp.  The Epson portion can
   > also be compiled into Ghostscript as a driver, and there's no
   > particular reason why the other drivers (HP and Canon) couldn't
   > receive the same treatment.  Quite a few people use it as a
   > Ghostscript driver, in fact.

   Ok.  Interesting, so you are basically a raster->printer driver.  I
   want that on gnome-print and I want to work on a common foundation.

It's GPL.  You're welcome to use it in any GPL project.  I'd be happy
to help you (with whatever time I have; I'm already stretched rather
thin), but I want to make sure you know what you're doing here.  I
don't particularly agree with the direction you're trying to take
(doing the rendering yourself), and I think you're just going to get
into trouble in the long run by doing that.

And yes, I say that from the perspective of someone who's already gone
there.  The application -- and application libraries -- isn't the
place to be doing rendering.  Device libraries and drivers should be
doing that.

I've already explained why I started with the Gimp print plugin.  The
Gimp is absolutely the wrong place for the rendering engine.  It's
there because right now we have nowhere else to put it.  Gnome is a
better place than the Gimp, but it's still not the right thing to do.

   If I interrupted in the list, it was only because Sven pointed me that
   GNOME print had not been brought up, and we all want the best for
   Unix.

I don't have a problem with that.  Sven (and Chema) should be telling
you what's going on here, and you're of course welcome to jump in.

   Hey we are using GnomePrint in about eight different applications in
   GNOME constantly, and people are printing their things with it.  The
   sooner we can get raster->printer drivers into GnomePrint, the
   better. 

I disagree with your direction.  The sooner you can hook up with a
good system-level technology, the better.

   The "dump to ghostscript, process, send to printer" solution is
   exactly what I believe to be fully broken for Unix to succeed on the
   desktop.  We have the infrastructure now to do things right, and I
   want to do this.

Right, but Ghostscript isn't what's at fault.  It may be ugly, but
it's not the root of the problem.

   > I think you'd be better off trying to implement the best possible
   > printing API for GNOME.  The Caanvas stuff looks reasonable (I'm not a
   > graphics person myself), but the low level stuff needs to be handled
   > by highly tuned code that's quite printer specific.  You say you want
   > to leave 6-color output (CcMmYK or CcMmYy, or for that matter CcMmYyK)
   > for another day, but that's precisely the wrong approach to take for
   > people who want high quality output on paper.

   I did not say that.  Did I?  I forget saying that.

http://developer.gnome.org/arch/imaging/printing.html:

	Lots of extensions are possible here. PostScript supports bitdepths
	larger than 8bpp, and CMYK color spaces. Other extensions we may want
	to support include larger color spaces (eg 6-color hifi color), and
	RGBA images. But those are best left for another day.

   > I think Mike has the right idea with CUPS.  Ignore gimp-print for the
   > moment, and ask yourself whether CUPS could live under gnome-print as
   > a sort of virtual printer.  I think that properly speaking gimp-print
   > and gnome should have nothing to do with each other, beyond the fact
   > that eventually the Gimp will print through something like
   > gnome-print, which will package everything up for CUPS.  At that
   > point, the core of gimp-print might be a back end driver within CUPS.

   I do not follow this, but it is ok.

That's the root of the whole issue.  We're producing some very high
quality drivers for printers.  Beyond being able to discover and
control their use of features, GNOME shouldn't get involved in that
stuff.

(Sorry.  It's late.  I'm not being too coherent, am I?)