gimp-print-devel

[Gimp-print-devel] Re: Yet another attempt at 'black'

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

   Date: Tue, 23 May 2000 19:42:53 +0200
   From: Thomas Tonino <tt...@bi...>

   I hope the version that's now in CVS does the right thing. It seems to
   do here.

   Suggestions for plain paper: lb = 0.1, ub = 0.5
		  coated paper: lb = 0.3, ub = 0.999
		  glossy paper: lb = 0.5, ub = 0.999

   Robert, do you think we can put in the dither matrices in a useful
   manner? I'm rather happy with them. Seems to give a crisper image than
   the error diffusion dithers. But if it is no good yet for more advanced
   printers, I will update my test version and put it in cvs.

Could you put these in for the appropriate paper types in print-escp2.c?

   I haven't tried the ordered dither for a while though. It seems so much
   better than the current ordered dither that it wouldn't hurt to exchange
   it.

It's a bit grainier, but overall a big improvement.  However, when I
look at it under a loupe, I see artifacts that look a lot like error
diffusion artifacts -- long, squiggly lines.  I'm quite sure I used
ordered dither on that print, though.

-- 
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 stuff

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

   Date: Tue, 23 May 2000 22:22:50 +0200
   From: Frank van Maarseveen <F.v...@in...>

   > the image is vertically shifted about 1 centimeter. The printer prints the
   > top of the page first. Instead of starting with a 3 mm white margin the
   > margin looks 13mm. But only 3 mm of the picture is left out. At the bottom
   > of the page (printed last) the last 3mm are unused but about 13mm of
   > the picture is left out. Left and right sides are ok (both 3 mm left out).

   Now things looks much better. There is no positioning error anymore (or
   it's sub-millimeter). The only cosmetic thing is a little asymmetry in
   the top and bottom margin. The first is practically 0 mm and the latter
   is approximately 7.5 mm.  Both left and right margin are still 3 mm.

There's little we can do about the bottom margin; the printer simply
can't hold the paper down there.

   I also grabbed http://www.tiac.net/users/rlk/colors.tif and printed it
   on an epson 740 using:

	   gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=12 -dDensity=0.8
		   -r1440 -sPAPERSIZE=a4 -dImageType=2 -dQuality=6 -dDither=4
		   -sOutputFile=out.esc a4.ps

   This really makes a difference compared to the original uniprint
   driver. The colors seem to fade into black a little too fast (to my taste)
   and the dithering there is slighly less good compared to when the colors
   fade away into white. I haven't played with the parameters yet. Overall
   the picture is very good.

We don't have the variable dot size stuff quite right yet.  Jean-Marc
Verbavatz is hard at work on it, though, and I think we'll see some
big improvements soon.

-- 
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] Updated print-dither

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

   Date: Tue, 23 May 2000 23:54:05 +0200
   From: Thomas Tonino <tt...@bi...>

   Frank van Maarseveen wrote:

   > What's the downside for using really big matrices (except for matrix
   > generation time I mean)? can it cause blurred pictures?

   No, but it could cause slower printing if the matrix doesn't fit in the
   processor cache.

Which suggests that we should access the matrix as [y][x] (I never
remember which one's row major and which one's column major).

   Now in theory, this matrix is worse than error diffusion. Error
   diffusion can adapt the raster to the features of the subject. But in
   practice, it adapts the ratser to pixels it has already printed, leading
   to squiggly lines in your printout. My result so far show the fixed
   matrix winning in light areas (error diffusion tends to form squiggly
   lines there) while error diffusion is better in dark areas, as it is
   more regular: very small regular things don't show very well.

Yup, the ordered diffusion is a bit grainy.  Part of that's due to a
simple bug in how the matrix is scaled to 0-64K (it has to be scaled
using long long arithmetic to avoid overflow), but that's not the
whole thing.  However, the matrix is infinitely more pleasing than any
of my efforts in this regard.

I'm probably going to 

   So the preferred solution is to use a matrix for low densities, and go
   to error diffusion when dots get close together.

Right, that's what the adaptive dither methods do.

Overall, this stuff looks really, really good.  The black threshold is
a bit low for my taste on the 870, but that's tunable.

I'm going to commit my changed black thresholds for variable dot size
printers, and your matrices (although I'm not going to tune use of
those matrices).  Then I'd like to give Jean-Marc a chance to catch
up; it looks from the commit messages like he has some stuff ready,
but he needs to merge in the latest changes.

Then we need to figure out the right thresholds for various paper
types and put them in print-escp2.

-- 
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] New UI stuff

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

I find the new way of presenting the image position very confusing.
It's evidently being presented as the distance from each edge (rather
than from the (top,left) origin as before).  It doesn't give me any
feedback on what the size of the image is, so I can't (for example)
simply space the image over by one image width.

-- 
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] Updated print-dither

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

Frank van Maarseveen wrote:

> What's the downside for using really big matrices (except for matrix
> generation time I mean)? can it cause blurred pictures?

No, but it could cause slower printing if the matrix doesn't fit in the
processor cache.

> One of the ideas I got was that it migth be possible to use multiple
> matrices, to use a bigger one only when the final color error after
> dithering gets too big. Put simple, if you have only four intensities
> for a certain color and one dot size then the possibilities could be
> represented by a 2x2 matrix
> 
>         |  |    |X |    |X |    |XX|    |XX|
>         |  |    |  |    | X|    | X|    |XX|
> 
> (randomization left out). So, if the intensity is 75% three dots
> of four would be a perfect match. When the intensity is 70% the
> error would be 5% for this matrix. But of course not with a lot of
> larger matrices.

Actually, we use one matrix for all color levels. Your matrix would look
like:

02
31

The input value is compared to the value in the matrix that matches the
place where we want to print. If it is higher, we print a dot.

Now back to your suggestion. If we print a value that matches a very
small matrix, the patterns would be very regular. If it wouldn't we
would pick a large matrix, which would have an irrecular pattern. This
doesn't look good.

But the killer for your idea is that we use just one matrix for printing
all the densities. It is not like having:

|X X|
| X |
|X X| <- Use this one when printing 50% black

And an immense number of other matrices for every density.

But more like:

|471|
|825|
|639| <- Print dots that are higher than the value in the matrix

Now the problem is placing the numbers in the matrix in the right
sequence. The program I wrote to do this starts with the first 4 dots
placed with human insight. After that, it checks each position for
distance to other dots. The one that is farthest away gets the next
number, and we go on looking for the next empty position that is far
away from other dots.

Well, actually looking for 'far away' doesn't work, because if a dot is
8 pixels from your left, it is 10 from your right. Adds up to 18. Now if
you step aside, that would still add up to 18. That's why I munge the
distance before adding, so close distances have more weight. I also add
a bit of random, or we would get into trouble with very regular
matrices. The problem with regular patterns is that the eye is very
sensitive to them.

Another interesting part is using the matrix. You cannot use exactly the
same matrix for different colors. My current preference is to shift the
matrix to the left or bottom for the different colors.

Now in theory, this matrix is worse than error diffusion. Error
diffusion can adapt the raster to the features of the subject. But in
practice, it adapts the ratser to pixels it has already printed, leading
to squiggly lines in your printout. My result so far show the fixed
matrix winning in light areas (error diffusion tends to form squiggly
lines there) while error diffusion is better in dark areas, as it is
more regular: very small regular things don't show very well.

So the preferred solution is to use a matrix for low densities, and go
to error diffusion when dots get close together.

> Maybe I'm talking nonsense or it is already being done. Anyway, I
> don't seem to have the time/FS knowledge to work it out so instead
> I drop it here on the list.

Thanks for the idea. It is in some ways desirable to have an optimized
matrix for every level to be printed, which is what you suggested. But I
do not see a solution how one can switch from one level to another
without creating seams, unless the matrices are really all the same.


Thomas

[Gimp-print-devel] Yet one more black update

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

I was not happy with the dark area performance and devised a fix.
Previous experiments showed that subtracting all K from CMY was better
than subtracting K squared.

I now subtract less than the generated K until the upper limit for the K
generation is reached.

I put all this in a spreadsheet that helped me figure out what is going
on. Basically it tries values of CMY from white to black and does
exactly what the color separation program does. It plots CMY and K vs
input level. It also plots C+K as an upper bound to density and
c^2/1.3^K^2 as a lower bound to density.

Observations:

The whole thing works in a nonlinear domain. If the starting level for
black is 0.5, that really means it is at half the number of dots
compared to full coverage, i.e. pretty dark. So 0.2 starting level does
not add black to skin tones.

No black is generated under the lower black level, but some CMY is
always used above the upper black level. At the lower black level, black
generation starts at 0 with rate of increase also 0.

At 100% coverage, only black is printed.

With lower bound at 0 and upper bound near or at 1, there is still CMY
used. To get rid of all CMY, the upper bound must be set extremely low.
0 and 1 produce as much cyan as black around the 35% coverage level -
for darker colors black starts to dominate.

If you want to get rid of all K, set the lower bound to 1 and the upper
bound a tad above.

Upper bound and lower bound can not be equal, or division by zero
occurs.

I hope you like it!


Thomas

Re: [Gimp-print-devel] Epson stuff

[Frank v. M. <F.v...@in...>]

On Sat, May 13, 2000 at 08:10:23PM -0400, Robert L Krawitz wrote:
> I fixed a major bug in the vertical positioning stuff.  Everyone who
> prints in color should grab this one.
Yesterday I imported gimp-print CVS into a downloaded version of the
ghostscript 6.23 source RPM announced earlier on this list. Some time
ago I reported a positioning error for the Epson 740, to recall a snippet:

> the image is vertically shifted about 1 centimeter. The printer prints the
> top of the page first. Instead of starting with a 3 mm white margin the
> margin looks 13mm. But only 3 mm of the picture is left out. At the bottom
> of the page (printed last) the last 3mm are unused but about 13mm of
> the picture is left out. Left and right sides are ok (both 3 mm left out).

Now things looks much better. There is no positioning error anymore (or
it's sub-millimeter). The only cosmetic thing is a little asymmetry in
the top and bottom margin. The first is practically 0 mm and the latter
is approximately 7.5 mm.  Both left and right margin are still 3 mm.

I also grabbed http://www.tiac.net/users/rlk/colors.tif and printed it
on an epson 740 using:

	gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -dModel=12 -dDensity=0.8
		-r1440 -sPAPERSIZE=a4 -dImageType=2 -dQuality=6 -dDither=4
		-sOutputFile=out.esc a4.ps

This really makes a difference compared to the original uniprint
driver. The colors seem to fade into black a little too fast (to my taste)
and the dithering there is slighly less good compared to when the colors
fade away into white. I haven't played with the parameters yet. Overall
the picture is very good.
I asked someone to try a similar thing on a Epson 740 using Windows plus
Epson supplied software for a dither comparison (to be continued...).


Thanks.

-- 
Frank

Re: [Gimp-print-devel] Updated print-dither

[Frank v. M. <F.v...@in...>]

On Tue, May 23, 2000 at 12:04:11AM +0200, Thomas Tonino wrote:
> I'm not putting in the new dither matrices myself. Maybe in a test
> version, but I'd like it tried on six-color printers before it is
> committed to the main tree.
What's the downside for using really big matrices (except for matrix
generation time I mean)? can it cause blurred pictures?

One of the ideas I got was that it migth be possible to use multiple
matrices, to use a bigger one only when the final color error after
dithering gets too big. Put simple, if you have only four intensities
for a certain color and one dot size then the possibilities could be
represented by a 2x2 matrix

	|  |	|X |	|X |	|XX|	|XX|
	|  |	|  |	| X|	| X|	|XX|

(randomization left out). So, if the intensity is 75% three dots
of four would be a perfect match. When the intensity is 70% the
error would be 5% for this matrix. But of course not with a lot of
larger matrices.

Maybe I'm talking nonsense or it is already being done. Anyway, I
don't seem to have the time/FS knowledge to work it out so instead
I drop it here on the list.

-- 
Frank

[Gimp-print-devel] CVS updated

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

Hi list,

I did complain about the black generation, but my posting that I did
update it to solve the problems with black in darker colors didn't make
it to the list.

While it is not perfect, it is much better than the previous version.
The upper bound for black generation can be safely set low - so can the
lower bound. There should be a factor of 2 between them at least if the
upper bound is much lower than 1.

If set very low - say 0.05 and 0.3 - good if somewhat dull results are
obtained. Little ink is used, which makes it good for simple papers.

To get the old behaviour, the lower bound would be set around 0.8 and
the upper bound at 0.999. That's good for really nice paper.

On the batch of coated Canon ink jet paper that I use, I achieve best
results around 0.25 and 0.7.


Thomas

[Gimp-print-devel] Black generation not perfect

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

Looking at a few more test prints, I feel that dark colors leave room
for improvement. Some dark colors show very little contrat, while they
did on some older test prints.

Those old prints were made with a version that left some color when
printing 100% black. Could be nice for a 'photo' setting in the driver
maybe.

But beyond that, I feel I must be able to do better than what's in now.
One of my test pictures has distant trees. Somehow, detail in the leaves
gets lost. They still look like trees though.

One more thing for those who care: 360 dpi positioning seems to be
broken. The result is always printed at the top of the page, at least
for the Stylus Color 600. It's pretty useless anyway because it is so
light, so I won't care much.


Thomas

[Gimp-print-devel] Yet another attempt at 'black'

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

I hope the version that's now in CVS does the right thing. It seems to
do here.

Suggestions for plain paper: lb = 0.1, ub = 0.5
               coated paper: lb = 0.3, ub = 0.999
               glossy paper: lb = 0.5, ub = 0.999

Robert, do you think we can put in the dither matrices in a useful
manner? I'm rather happy with them. Seems to give a crisper image than
the error diffusion dithers. But if it is no good yet for more advanced
printers, I will update my test version and put it in cvs.

I haven't tried the ordered dither for a while though. It seems so much
better than the current ordered dither that it wouldn't hurt to exchange
it.


Thomas

Re: [Gimp-print-devel] Updated print-dither

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

   Date: Tue, 23 May 2000 10:19:24 +0200
   From: Thomas Tonino <tt...@bi...>

   720 dpi printing didn't show this, but 1440x720 dpi shows this problem
   for me. It also shows really strange patterns on the light side. I'll
   comment out black and set it to zero instead and see if those disappear
   as well, or if there is a more complex interaction.

My guess is that it's the density issue.  A useful test that I've
found is to print at a density of 0.1.  This is, of course, not very
useful in practice, but it saves a lot of ink in testing and it's good
for flushing out density-related problems.

BTW, the new matrix looks promising.  The texture isn't perfectly
smooth, but the grain is quite even.  There could be any number of
reasons why that is the case.  It looks like there might be a
sprinkling of larger dots mixed in.

-- 
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] Updated print-dither

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

Robert L Krawitz wrote:

> There's one odd thing I'm seeing: printing colors.tif, in the dark
> half where two of the three colors are mixed, there's a black bar.  It
> looks like it's using black heavily when any amount of the third color
> is present and two of the colors are heavily present.  You might want
> to play with escp2-unprint to see what I'm talking about.

720 dpi printing didn't show this, but 1440x720 dpi shows this problem
for me. It also shows really strange patterns on the light side. I'll
comment out black and set it to zero instead and see if those disappear
as well, or if there is a more complex interaction.

I do most of my testing in 720 dpi, byt the way, as something seems to
be wrong with 1440x720. I guess I should test over a wider range of
settings at least.


Thomas

[Gimp-print-devel] Thorsten's patch for gimp_main_window.c

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

I just comitted Thorsten's patch (same as last night's version for the
GTK gui) for the Gimp gui.

Steve
 
-----------------------------------------
Madness takes its toll.  Please have exact change.
------------------------------------------

[Gimp-print-devel] Another really big difference...

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

The woman's hair (lower left).  The Windows print has some nasty black
splotches; we're almost free of that effect.

[Gimp-print-devel] Comparison

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

Someone at work printed me the PDI target using the Windows driver in
highest quality mode (but not photo enhanced) on his STP 750.
I compared my two best test prints against the Windows driver.

Overall, I think I like our rendition better.  Both of our test prints
have some flaws, but so does the Epson print.  Keep in mind that
although we're comparing an 870 to a 750, we're using exactly
identical settings for both printers.  If there is a way to print even
more dot sizes on the 870 (which there might be), we don't know about
it yet (until someone dumps a test print to a file from Windows and
runs parse-escp2 on the output).

1) Our prints are more saturated than Epson's, and comparing it
   visually to my monitor, ours is more accurate in that regard.
   That's not an entirely fair comparison because I'm using a
   saturation setting of 1.1.

2) Skin tones: our darker skin tones (the first and third from the
   left) are considerably better.  They win by a small amount on the
   light skin tones (ours are a touch yellow).

3) The Macbeth color chart is a toss-up, and a matter of preference.
   We're a bit dark and saturated; they're a bit pale and muted.

4) Pale areas, interestingly enough, I think we win on.  They're
   smoother overall but some of their light areas have small dark cyan
   speckles which are noticeable.  This is most noticeable in the
   yellowish area near the light bulb about 1/4 way down on the right,
   but it's also visible in some of the panels of the Macbeth chart.
   That's probably a specific bug in their driver.

5) The gold PhotoDisc logo at the extreme top left: their gold is
   muted and somewhat tan; our gold color is very good.  We win.

6) Resolution is a toss-up.  Neither printer can match a quality
   photographic print at a reasonable size (photographic enlargement
   does better on smaller prints; printers do not lose resolution as
   the size increases).  The fine text is equal on both prints (I was
   a bit concerned about that).

7) Grays: they're slightly reddish overall, we're a bit green and the
   cast varies with density.  They win here.

8) Banding: equally invisible, except at the top and bottom of the
   page, where we lose badly.

9) Dark colors: we win here, rather to my surprise.  Their rendition
   of the leftmost four columns of the Heidelberg chart is very
   grainy, and grain is also quite noticeable in the middle of the
   three CD's in the top right.

Again, though, we needed two prints (with different strengths and
weaknesses in both) to do well.  I think that the stuff I checked in
over the weekend, in combination with a better matrix, would solve a
lot of our remaining problems.  Notice that our weaknesses are in the
grays and in some cases smoothness.  When Jean-Marc and Thomas are
done, I think we'll have some really good answers there.

This all said, all of these are amazingly close in quality to a
photographic print.  If the 870 can support more dot sizes, it should
be possible to do really spectacular prints.

-- 
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] Updated print-dither

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

   Date: Tue, 23 May 2000 00:04:11 +0200
   From: Thomas Tonino <tt...@bi...>

   For higher quality paper, 0.5 and 0.999 is good. There is probably a lot
   in between - and meybe even beyond for the very high quality papers.

There's one odd thing I'm seeing: printing colors.tif, in the dark
half where two of the three colors are mixed, there's a black bar.  It
looks like it's using black heavily when any amount of the third color
is present and two of the colors are heavily present.  You might want
to play with escp2-unprint to see what I'm talking about.

   I'm not putting in the new dither matrices myself. Maybe in a test
   version, but I'd like it tried on six-color printers before it is
   committed to the main tree.

The matrices themselves (at least the 257) look pretty 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

[Gimp-print-devel] Updated print-dither

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

I updated print-dither.c once more. It is now all scaled to d->density,
so things should work over a variety of resolutions.

I took out the ink density limitation: it went very ugly on me on a dark
red. Enough reason to take it out.

I tested a variety of settings. Using high amounts of black now is
useful for plain paper printing. The results with lower bound = 0.1 and
upper bound = 0.5 look decent on normal fibrous paper.

For higher quality paper, 0.5 and 0.999 is good. There is probably a lot
in between - and meybe even beyond for the very high quality papers.

Keep in mind that using a better dither for black will hide black
better. The patterns can jump in your face right now.

I'm not putting in the new dither matrices myself. Maybe in a test
version, but I'd like it tried on six-color printers before it is
committed to the main tree.

My experiments with the distributed dithers actually brought me to
change the black generation mechanism, and the two seem a happy match,
although I tried today's update only with the current dithers.

Questions? Feel free to ask.


Thomas

Re: [Gimp-print-devel] Printing in KDE 2.0

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

Waldo Bastian wrote:
> ...
> I suggest to adopt sysAPS as API to access the operating systems
> printing system, e.g. CUPS or LPR:
> 
> KDE -> sysAPS -> IPP -> CUPS -> filters -> driver -> backend
>               -> LPR -> filters -> driver -> backend

Actually, with LPR the "backend" doesn't exist.  You write to a file
or to a socket.

> ...
> Based on sysAPS it will be relatively straightforward to meet KDEs
> printing requirements:

I agree.  One word of "warning" - I have heard (but not confirmed
myself) that the sysAPS interfaces are more difficult than they need
to be.  As you say, it is still a young library, but you should
definitely push for changes if you see something that will cause
problems down the road.

> ...
> *) The proposed printing architecture is not limited to Postscript
> output, although that is what the Qt printing classes produce.

I encourage you to stick with PostScript unless another vendor-
neutral format becomes available.  PCL 6 (aka PCL XL) *might* be
usable as an output language (vector + support for CMS and "deep"
images) if someone does a PCL 6 RIP (non-PS printers) and filter
(PS printers), however it's a lot easier to code for and debug
PostScript output than it is to do for PCL 6 output...

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

[Gimp-print-devel] Printing in KDE 2.0

[Waldo B. <ba...@kd...>]

Comments on the following proposal are highly appreciated. 

Cheers,
Waldo Bastian

RFC: Printing in KDE 2.0
========================
Date: May 22, 2000
Author: Waldo Bastian

Printing support in KDE has not been changed since KDE 1.1.2. As such
it is not completely up to spec with the rest of KDE 2.0. In this document 
a printing architecture for KDE 2.0 is proposed.

Requirements
============

Four different desired printing related abilities can be identified 
within KDE:

1) The ability of a user to select a printer from the list of installed 
printers to be used for a print request and to select, possibly 
application specific, options for the print request.

2) The ability of a user to be notified of the status of his outstanding
print requests and the ability for the user to cancel outstanding print
requests.

3) The ability of an application to query the properties of the printer
used for a certain print request as well as options specified by the user
for this specific print request.

4) The ability of a user to add and configure a printer.


Status in KDE 1.1.2
===================

Ad 1) QPrintDialog provides this functionality in KDE 1.1.2. The drawbacks 
are that this dialog does not fit in well with the KDE translation meachanism
and that it is not possible to add application specific options to this 
dialog.

Ad 2) In KDE 1.1.2 applications exists which provide this functionality. The 
user has to start these applications explicitly. There is no integration
with the application that issued the print-request.

Ad 3) The QPrinter class provides basic information about the printer and
the specific print request, mostly based on information supplied by the user.

Ad 4) KDE 1.1.2 provides no way to do this.

Proposed KDE 2.0 printing architecture
======================================

I suggest to adopt sysAPS as API to access the operating systems printing 
system, e.g. CUPS or LPR:

KDE -> sysAPS -> IPP -> CUPS -> filters -> driver -> backend
              -> LPR -> filters -> driver -> backend

Other printing systems can be supported by adding support for them to sysAPS.

To quote the sysAPS homepage:

"This project, driven by Corel, provides a unified API for accessing 
printing-specific services outside the realm of the graphics API. This 
includes querying & controlling features of a given printer model, sending 
jobs, accessing queues and configuration."

sysAPS is under LGPL, is written in C and has both a C as well as an optional 
C++ API. It is a rather young project so it should not be a problem to adapt 
to any specific wishes in the API. You can find them at 
http://sourceforge.net/project/?group_id=2328.

Based on sysAPS it will be relatively straightforward to meet KDEs printing
requirements:

1) A KPrintDialog based on KDIalogBase should be made. It can use sysAPS
to query for available printers and enable/disable available options
based on the capabilities of the selected printer.

2) A notification/control interface should be made for printing job-control.
sysAPS seems to provide all necassery functionality. We only need to provide
the UI. Maybe this can be part of kio_uiserver. Maybe it should be made a
seperate application.

3) For now the QPrinter class seems to be adequate. It might be desirable to
embed this class in a KPrinter class to make it possible to add KDE wide
options not provided by Qt. In addition this class could give access to 
a printer's PPD file allowing applications to fine tune their print output.

4) A kcontrol module should be written which allows printer configuration.
sysAPI seems to provided al necassery functionality. Only the GUI part needs
to be added.


Considerations
==============

*) The proposed printing architecture is not limited to Postscript output, 
although that is what the Qt printing classes produce.

*) The proposed sysAPS library can be used by non-KDE applications, including
command line tools. Although the GNOME project is not interested in
cooperation in this area, there are no compelling technical reasons which 
prevent them from adopting sysAPS, now or in the future.

Re: [Gimp-print-devel] Raph's stuff

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

On Mon, May 22, 2000 at 09:52:52AM -0000, Karl Heinz Kremer wrote:
> No, it's awfully silent from their side. I just sent a reminder
> that there are still some open issues. 
> 
> As soon as I get some information I'll relay it to the list.

Should others start sending requests for documentation to
is...@er...?

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

Re: [Gimp-print-devel] Raph's stuff

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

Hrafnkell Eiriksson <he...@kv...> said: 
[ ... ]
> 
> Has anyone  heard anything from Epson about when they will release
> the specs of the Stylus 660 printers?

No, it's awfully silent from their side. I just sent a reminder
that there are still some open issues. 

As soon as I get some information I'll relay it to the list.

Karl Heinz

Re: [Gimp-print-devel] Raph's stuff

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

On Sun, May 21, 2000 at 09:47:08PM -0400, Robert L Krawitz wrote:
> Is anyone interested in looking at Raph's rinkj stuff?  I've only had
> a chance to look at it very briefly, and it will take some work to
> interoperate with our framework, and I'm not going to have a whole lot
> of spare time to fiddle with this right now.

I'd be interested as soon as I finish my exams and have handed in
the last report. That should be the first week of june.

Has anyone  heard anything from Epson about when they will release
the specs of the Stylus 660 printers?

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

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

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

   Date: Mon, 22 May 2000 11:02:03 +0200
   From: Thomas Tonino <tt...@bi...>

   Which of course has the same black curve but lets CMY exist until K hits
   limit. The first option gives more control and I think it is more
   correct, at least if ink densities match.

We want pure black to be printed using pure black ink.  This will make
text look good, and will also improve performance.  That's why
d->density is the right cutoff.

   Robert, if you could have a look at the use of 65536 versus d->density
   and other scaling issues - I'd prefer to know they are right - but from
   your results I gather there may be a scale problem somewhere. Or maybe
   you could document a bit more on meanings of variables and expecially
   their ranges. I'm wondering for example why print_color gets called with
   bk, bk and k.

print_color has the following calling sequence:

print_color(dither_t *d, dither_color_t *rv, int base, int density,
	    int adjusted, int x, int y, unsigned char *c, unsigned char *lc,
	    unsigned char bit, int length, int invert_x, int invert_y,
	    unsigned randomizer, int dontprint, unsigned *ink_budget)

base, density, and adjusted all represent in some form the level of
the color being printed:

* base is the level used to decide whether to use Floyd-Steinberg or
  ordered dither if adaptive dithering is used.

* density is the level used to decide which tone (for variable dot
  size/6 color printers) to print.

* adjusted is the level used to decide (in combination with the choice
  of tone) whether to print at all.

base and density should be between 0 and 65535.  adjusted should be
between -65536 and 65535.

-- 
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:

> The two issues with using a lot of black are:
> 
> 1) Heavy black dots in areas not dark enough to mask them.

This came out fine on my end with these settings. A bit more grainy than
before, but still less grainy than lighter tones. But much better dark
tones.

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

Yes, this is where I had the problem with the original code. Adding more
black (which is good on 4 color printers) made for non-monotonous gray
wedges. Anyway, I just thought up something to try tonight:

if ( k <= lb )
  kl = 0;
  ks = 0;
else
  {
    kl = ( k - lb ) / ( 65535 - lb );
    if ( k <= ub )
      ks = ( k - lb ) / ( ub - lb );
    else
      ks = 65535;
  }

The idea is:

0       lb           ub     65535
+-------+------------+------+
+---------------------------+ range of K
        +-------------------+ kl goes from 0 to 65535 over this range of
K
        +------------+        ks goes from 0 to 65535 over this range of
K

And then:

k = kl * ks;
c -= c * ks * ks;
m -= m * ks * ks;
y -= m * ks * ks;

This allows good control. A test in a spreadsheet also 'looks correct'
in that CMY builds up almost linearly. At lb, K sets in slowly and CMY
continues to rise. At ub, black rises more slowly as CMY hits 0.

Or maybe:

k = kl * ks;
c -= k * k;
m -= k * k;
y -= k * k;

Which of course has the same black curve but lets CMY exist until K hits
limit. The first option gives more control and I think it is more
correct, at least if ink densities match.

Robert, if you could have a look at the use of 65536 versus d->density
and other scaling issues - I'd prefer to know they are right - but from
your results I gather there may be a scale problem somewhere. Or maybe
you could document a bit more on meanings of variables and expecially
their ranges. I'm wondering for example why print_color gets called with
bk, bk and k.

The 257 x 257 matrix is making progress: it is at 1/4th now. With luck,
it is ready tonight: the first part takes longest.


Thomas