gimp-print-devel

Re: [Gimp-print-devel] First experiences with an 870

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

   From: sh...@al...
   Date: Fri, 19 May 2000 11:51:47 +0900

   > (when I want to release 3.1.5, how do I make sure everything gets
   > built?).

   ssh linux.compile.sourceforge.net
   cd print
   cvs update
   ./build_packages
   ls

   Of course, someone would need to write the "build_packages" script, but
   it wouldn't be that difficult to do.

I like this virtual stuff!  Yeah, I think this could be done.

Re: [Gimp-print-devel] First experiences with an 870

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

>    How should we upload these packages to the sourceforge server?
> 
> That's a good question.  We could create separate file releases for
> each different packaging format (tarball, .deb, various .rpm), but
> then we'd have the monumental headache of keeping everything in sync

Not really.  Not if we could use the compile farm.  (Assuming the farm
would be upgraded to include Debian.)  Then a single script could
build packages for all major distributions.

> (when I want to release 3.1.5, how do I make sure everything gets
> built?).

ssh linux.compile.sourceforge.net
cd print
cvs update
./build_packages
ls

Of course, someone would need to write the "build_packages" script, but
it wouldn't be that difficult to do.

Eric

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

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

Miguel de Icaza wrote:
> 
> > This is one issue that has come up before: aside from maybe
> > providing a basic driver for PCL printers, I don't think the
> > right "solution" is to embed drivers in the applications.
> 
> The PCL driver just happens to be the first driver that has been
> developed on top of the generic RGB rasterizer.
> 
> It is not a "basic" driver for PCL printers, it is designed to print
> perfecly beautiful pages on pretty much every PCL printer in
> existance.

Well, I wish you good luck, then.  However, please accept my
advice (from developing PCL drivers for 12 years) that any driver
you are likely to develop will not handle all printers or provide
optimal output.

> ...
> I looked "below" and never found anything relevant, nor a way to
> sustain your claim of "not scale".  New device drivers are just new
> shared library object files.  Your point?

"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.

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?!?

> ...
> Well, then they would have to compile a few extra packages.  What is
> the big deal?   You suggest that reimplementing all of the GNOME

There are a substantial number of packages that *don't* get used
because of dependencies on other large packages.  GNOME is no small
thing.

> dependencies into gimp-print is a better approach for the sake of
> "those that dont have GNOME installed"?  It seems like the benefits
> outweight the problems.

The thing is, all of the "enhancements" you've suggested are
easily added to PostScript output *without* GNOME code.

> Good.  Then we just need to use modified PPD files as our
> "repository" for information.  Next?

You don't get it - you can use PPD files that the printer drivers
(external from GNOME) provide; GNOME just needs to output PostScript.

This method works for both CUPS and LPD based printing, BTW.

> ...
> You can just link with PPD and expose its internals trough the same
> API you would access our configuration data.

Again, the problem is keeping the driver data in sync.  Unless you
plan on embedding the information in each driver DSO, this task will
prove extremely difficult.

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

[Gimp-print-devel] Thorsten's patch

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

I finally got Thorsten's positioning patch merged and tested for the GTK
gui, and just commited it.  I could not get the gimp gui to compile with
it, so I only applied the GTK portion.  Mitch, can you take a look?  Its
probably something simple. If you don't have it I can email it.  The
double frame for printable area is a nice touch.  This still doesn't fix
the scaling error (I think that's what it is) that causes an image
positioned hard against the right edge to get clipped.

Steve
-- 
-----------------------------------------
Einstein discovered that time and space are interchangeable
when he showed up three miles late for a meeting.
------------------------------------------

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

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

   From: Miguel de Icaza <mi...@he...>
   Date: 18 May 2000 17:01:31 -0400

   It is not a "basic" driver for PCL printers, it is designed to print
   perfecly beautiful pages on pretty much every PCL printer in
   existance.

But will it print really high quality 6-color images from compatible
printers?

(That's a loaded question because our PCL driver won't, either, since
we haven't been able to get the specs from HP.  Ours will, however,
use variable dot size on printers with that capability.  Our Epson
driver will print to 6 color, variable dot size printers and take full
advantage of that ability.)

-- 
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] Latest results

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

   Date: Thu, 18 May 2000 16:26:33 +0200
   From: Thomas Tonino <tt...@bi...>

   The second is that I'm generting a new matrix now. It has somewhat
   reduced noise, but more interesting may be the change in selected
   initial points. The current matrix has starting points selected for
   minimum autocorrelation when shifted 1/2 H or V, the new matrix will
   shoot for 1/3 or 2/3 H and V. This gives 9 uses for a single matrix:
   enough for cCmMyYkK and yet another independent use.

That sounds very interesting.  I count two uses per color, or 8 total
(Cc are treated as one color).

   Robert, do you think 199 x 199 is big enough for a release version or
   would you prefer 251 x 251 or 257 x 257 ? That would make full of the 16
   bits internal resolution at least.

257x257 would be pretty much ideal, although there would be slight
excess resolution.

   In any case, the approximated version (which is much like the original)
   is delayed and blurred (by diffusing into other cells) as it is
   subtracted from the input. And what happens if a blurred version of X is
   subtracted from the original X: X is sharpened by making the low
   frequency components weaker. The process is also called 'unsharp mask'.

I think I get it.  This is why there's a blank area near a sharp edge
in some cases.

-- 
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] Latest results

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

   Date: Fri, 19 May 2000 00:26:17 +0200
   From: Thomas Tonino <tt...@bi...>

   Thomas Tonino wrote:

   > > Thomas, could you play around with your new matrix some more?  It's
   > > not in, because having only one matrix caused problems, but it does
   > > look promising.  It really bloats the executable, though.
   > 
   > I have a number of things I'm trying.

   It turns out the things that I'm trying don't work. While CMY dither
   works fine the transition to K just doesn't work out - even if I use
   rand() instead of a matrix.

Really?  I've been wondering if black should always be printed with
ordered rather than error diffusion (at least for reasonably high
values of k_lower).  It hasn't worked well thus far, but I wonder if
the thing I fixed last night might help it do better.

   This led me to believe that the current K generation needs error
   diffusion to give a decent result. I changed the following piece:

		 else if (kdarkness < ub) /* Probabilistic */
		   {
		    /*
		     * Calculate how much black we are going to shuffle away
		     */
		     if ( kdarkness >= lb )
		       rk = (kdarkness - lb) * ( ok / rb);
kdarkness will always be > lb here

   I have to set density a bit lower (to 0.9) and still the density of
   black seems too high.  I tried first with dither_set_black_lower(dither,
   .1 / bits) in print-escp2.c because that shows problems rather clearly,
   but with the above changes, the 'green problem' is fixed.

Interesting.  I've had a lot of trouble getting enough black most of
the time.  Could you send me a diff?

   Going back to .4 for dither_set_black_lower shows a problem: from light
   to dark, first CMY builds up. At higher density, K also starts to build
   p. Suddenly, CMY drops off to 0 while K is not up to maximum yet. So
   there definitely is a problem with the value of rk: maybe it's off by a
   factor of 65536?

More likely you're multiplying two ints, and when the product exceeds
2 GB you're flipping over into negative territory.  Switching to long
long arithmetic will show that up quickly.

   I do not have good insight currently in what kdarkness, ok, and others
   exactly do. I do know that what I see for dither_set_black_lower = 0.4
   demonstrates my code is wrong. I'd like to achieve something along the
   following lines:

kdarkness is supposed to represent the perceived "darkness" of the
point.  We don't want to use black in light areas.  "ok" means
"original k" (same for oc, om, and oy) -- the base values before any
error diffusion is done.

   /* if c + m + y is more than the paper can absorb, we determine which
...

This approach looks reasonable to me.  Let's think about it some
more.  I'm too wiped right now.

   It may even be possible to make this work with the right combination of
   the current variables. It just seems that using the binary dither result
   to adjust analogue input values is not a good idea for ordered dither,
   and it may not be a good idea at all.

Hmm.  It occurs to me that you might not have picked up my commit this
morning?  I changed it from an on/off result to a smoothly scaled
value.  Note this:

#if 0
		  if ((d->dither_type & ~D_ADAPTIVE_BASE) == D_FLOYD)
		    ditherbit = ((xrand() & 0xffff000) >> 12);
		  else
		    ditherbit = (DITHERPOINT(d, row, x, 1) ^
				 (DITHERPOINT(d, row, x, 3) >> 2));
		  ditherbit = ditherbit * rb / 65536;
		  if (rb == 0 || (ditherbit < (kdarkness - lb)))
		    bk = ok;
		  else
		    bk = 0;
#else
		  bk = (ok - lb) * (ok - lb) / (ub - lb);
#endif

The code that's in use is that last line, which scales bk smoothly
between 0 and ub as kdarkness goes from lb to ub.

   It's late now. The new matrixc will be ready tomorrow morning, but I
   doubt it will make a significant difference if rand() causes the same
   problems as re-using the matrix. Maybe K doesn't register exactly with
   CMY or so - in any case, K buildup in the old code looks very clustery.

I think I understand now.  I'm going to try to reprint from my EX onto
a piece of Epson photo paper, rather than the third party stuff that
has problems with the Epson ink.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] First experiences with an 870

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

   Date: Thu, 18 May 2000 23:59:39 +0100
   From: Charles Briscoe-Smith <cp...@de...>

   I had imagined the interpolator to be a separate module, in the same
   way that the ditherers are.  Then the dithering code would pass the two
   lines bracketing its current position to the interpolator, and get back
   a line interpolated between them.  That assumes we're not going to use
   more than the four pixels surrounding any one point to determine the
   value of a point in between.  Maybe the more advanced interpolation
   algorithms use more surrounding points, in which case that wouldn't work.

Actually, as best as I can tell, all of the standard dithering
algorithms work on a row-by-row basis (even Raph's stuff).  There are
other ways to keep state around; that's what error diffusion does.

   Hmm.  The reason I was studying the weave code was because I was going
   to try to modify the weave pattern to make it print closer to the edges
   of the paper.  Since you've already done this, though, there's little
   reason for me to work on it too.  ;)

Other than the fact that the quality sucks at the top and bottom of
the page?  We do eventually hae to fix that.

   I noticed that your change to the weave pattern was much simpler than the
   way I wanted to do it.  It basically cuts off the top and bottom jets*sep
   rows and print them in a "naive" weave pattern, which unfortunately
   causes some patterning in that section of the print (on the 870 it's
   only really noticeable in fairly smooth areas like clear blue sky).

Likewise here.  I wish we only had to support the 870 :-)

   I've tried it, though, and I wasn't able to get it working.  This seems
   to be because of the assumptions that the softweave code makes.
   Specifically, it assumes that the last row of each pass occurs later
   than the last row of the previous pass.

There are a whole bunch of invariants it has to follow.  The most
critical one is that the virtual first row (where jet #0 would be
printing) of each pass must not be any earlier than the virtual first
row of the previous pass.  That's because the printer cannot space
backward.

I ALMOST got it working with a better pattern, but I didn't succeed.
The way to test this is to use escp2-weavetest.  It can take any
combination of jets, separation, passes, start and end rows, and
simulate the printer behavior.  It will tell you if there were any
errors and exactly where they were.

   > I won't put that one in tonight, but it's a good idea.  What's
   > SIGNULL, though?  I don't think it's POSIX.  Actually, you should get
   > a Sourceforge account and I'll add you as a developer.

   Sorry about the SIGNULL.  I put that there temporarily while I wrote the
   code intending to check it against the libc docs later.  When I checked,
   I found that signal number 0 doesn't have a constant defined for it, so I
   replaced SIGNULL with the literal 0.  I forgot to regenerate the patch,
   though.  Signal 0 is a signal that doesn't affect the target process
   at all; it just gives an error response from kill() if the process
   doesn't exist.  Its purpose is to enable you to see whether a process
   is still alive.  If it's no longer documented, there might be another
   way to do this now.  Actually I think I first read about it on SunOS,
   so maybe it's a SunOSism.

Actually, Linux does support that kind of thing, although it just uses
a signal number of 0.

   > If you're willing to get a Sourceforge account, let me add you as a
   > developer, and make the change on the other drivers (ps, pcl, and
   > Canon), go ahead.  It's not my favorite idea, but I must admit that it
   > would save some headaches in some cases.

   I've joined sourceforge, with username "cpbs".  I'll take a look at the
   other drivers, and see if I can do anything with them.  I doubt the PS
   driver will need any changes, since the postscript interpreter should
   clip to the printer's printable area.  I suspect PCL printers also clip.
   I'm fairly sure the Laserjet4 clips PCL commands: some years ago, when
   the LJ4 with its 600dpi was new, I hacked the (binary) laserjet driver
   of PageStream (an Atari DTP program) to do 600dpi output (and to do RLE
   compression when useful), and I think I saw the printer do clipping then.
   I don't know about Cannon.

Epson printers don't clip.  If you give it something wider than what
the printer can physically do, it will simply error out (or maybe the
print head will fly off the end of the printer and spill ink all over
your 1000 year old Persian rug).  If you give it something wider than
the paper, it will blithely dump ink all over the innards of the
printer.  Messy.

I've added you.

-- 
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] First experiences with an 870

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

   From: sh...@al...
   Date: Fri, 19 May 2000 08:37:20 +0900

   How should we upload these packages to the sourceforge server?

That's a good question.  We could create separate file releases for
each different packaging format (tarball, .deb, various .rpm), but
then we'd have the monumental headache of keeping everything in sync
(when I want to release 3.1.5, how do I make sure everything gets
built?).  I think there are other ways of releasing files on
Sourceforge, though, but they all have that problem.  So probably
creating separate file releases for each different format would be the
way to go.

-- 
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] An introduction to gnome-print (fwd)

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

   Date: Thu, 18 May 2000 09:00:42 -0400
   From: Miguel de Icaza <mi...@he...>

      It has been brought to my attention that you guys have been
   discussing the future of printer drivers and that you are debating
   high quality printer drivers for GIMP.

      I do not know the context of your debate, but I will want to
   introduce gnome-print to you guys, to consider you guys joining our
   effort to provide a complete imaging solution for Unix systems.

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.

If you take a look at the roadmap I drafted when I started this
project, you'll note that one of the goals is essentially to eliminate
the Gimp Print plugin by having it subsumed into something else (GNOME
Print, or whatever else comes along).  So I don't think we're all that
far out of agreement in the long run (strategically).  Tactically, we
may be.  More below.

   * What is GNOME Print

       GNOME print is an imaging API modeled after the Postscript imaging
       model, that is accessible trough a Gtk+-like C API.  This imaging
       model has two major extensions: support for an alpha channel and
       anti-aliasing.

There's nothing here that's particularly at odds with the gimp-print
engine (the dithering core and the print drivers).  If you grab a copy
of our source tree (or the 3.1.4 release) and look at print.h, you'll
see the following, which implements the interface to the upper part of
the driver (again, we have two upper parts, the Gimp plugin and the
Ghostscript driver).

/*
 * Abstract data type for interfacing with the image creation program
 * (in this case, the Gimp).
 */
typedef void *Image;

extern void Image_init(Image image);
extern int Image_bpp(Image image);
extern int Image_width(Image image);
extern int Image_height(Image image);
extern const char *Image_get_pluginname(Image image);
extern void Image_get_col(Image image, unsigned char *data, int column);
extern void Image_get_row(Image image, unsigned char *data, int row);
extern void Image_progress_init(Image image);
extern void Image_note_progress(Image image, double current, double total);

	   4. RGB rasterizer:  This is the most interesting part: this
	      driver can rasterize the printing commands sent to a
	      printing context and generate output as an RGB buffer for
	      the entire page (as an optimization, the RGB driver works
	      in 1-inch bands).

We can fit very comfortably under that kind of model.

	   5. A generic PCL driver (not yet fully plugged into the
	      system).   This PCL driver is just a "derived" class from
	      the RGB rasterizer.  

	      This driver contains a pretty neat set of compression
	      techniques to reduce the size of the file sent to the
	      printer. 

OK, here's where I think we disagree tactically.  Much of our effort
has been going into improving quality and support for specific
printers (particularly the latest Epson offerings -- the reason for
that is that HP and Canon have not been forthcoming with
information).  The fact that I printed a test image this morning on an
Epson Stylus Photo 870 and got something that really looks a lot like
a photograph (I'd say that the quality equals a marketing print that
Epson themselves made from a 1200) testifies to that.

To the best of my knowledge, there is no other open source software
that comes even close.  There are a few drivers around for the Stylus
Photo 700, a much older printer (two generations back) that is not
even remotely close to the quality of the 870, and our software does
quite well on that printer, too.

I want people who have Epson 800's and 600's and 700's and 740's to
get good output.  I also want people who want to be able to produce
photographic quality output from Linux to be able to do so NOW, not
two years down the road when gnome-print is complete.  I think that
that's just as critical, because people won't wait for everything to
catch up.

The Gimp was a good place for me to start from for a few reasons:

1) It's very demanding of output quality.  Printing photographs
   digitally is a very demanding test of quality.

2) The driver was a lot cleaner than anything else I saw (thanks, Mike
   Sweet!).

   * Why I believe GNOME print is a better solution than GIMP print, even
     for the GIMP.

	The GIMP print output is currently limited to printing bitmaps,
	it has no support for printing anything but that.    This limits
	its usefulness for adding other kind of information on its
	output. 

That's all well and good, but you've done much the same thing with
your PCL driver, and for good reason -- it's a lot more
straightforward that way.  And if you use gimp-print as a Ghostscript
driver, then it can render anything that Ghostscript can render.

	Hence, I would like to encourage people to use GNOME-print as
	your imaging API instead of your current native bitmap interface
	and to get hackers working on GNOME print to make it suit the
	imaging needs of the GIMP. 

Of course.  Maybe we should rename the project, since the name
gimp-print is misleading.

   * The future of GNOME Print

	   3. Add ICC support to GNOME print.

That sounds interesting, although one of our developers is also
working on color management.

	   5. Add support for using more of the features available in the
	      printer for "normal" output (ie, if the user does not use
	      any advanced feature from Postscript and just outputs text,
	      we can use the printer fonts if they happen to match the
	      ones we have, or we can download fonts + outputing just
	      text).

That's great, although a lot of low end printers don't support very
much of that.  But plain text output is already handled pretty well as
it stands; high quality graphics aren't.  And the way things are
moving, graphics output (which includes most text on all but
Postscript printers -- think about kerning and all that) is dominating
the printing scene.

This isn't meant as a flame, but I think there's a lot of stuff you
haven't taken into account here.

If I may offer my own commentary, I think that gnome-print is trying
to bite off too much by getting down to the device rendering and
driver level.  The Caanvas technique of rendering images in
fixed-width bands and sending them directly to the printer won't work
for Epson printers (as an example) because in order to do output
properly to Epson printers you need to interleave output rows in a
rather complicated pattern.  You simply can't render part of a page,
send it to the printer, render the next strip, send it, and so forth.
Well, you can, but you'll lose a lot of quality and/or performance in
the process.  You can render part of a page and send it to the printer
DRIVER, but the driver has to make the final decisions about how to
send the result to the printer.

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.

Once you get down to brass tacks, the output drivers for any of the
cheap, high quality ink jets do basically the same thing -- dither a
bitmap.  None of these printers support PostScript; none of them have
much in the way of built-in fonts (some of them can't even print plain
text shoveled down their throat), but with the right software driver,
even a low end inkjet (like the Epson Stylus 440) can make a laser
printer look like garbage by comparison.

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.

-- 
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: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Miguel de I. <mi...@he...>]

> This is one issue that has come up before: aside from maybe providing
> a basic driver for PCL printers, I don't think the right "solution"
> is to embed drivers in the applications.  

The PCL driver just happens to be the first driver that has been
developed on top of the generic RGB rasterizer.

It is not a "basic" driver for PCL printers, it is designed to print
perfecly beautiful pages on pretty much every PCL printer in
existance.

> It doesn't scale, address "corporate" issues like accounting, etc.,
> and can lead to all sorts of problems for new drivers, etc.  See
> more below...

I looked "below" and never found anything relevant, nor a way to
sustain your claim of "not scale".  New device drivers are just new
shared library object files.  Your point?

> I agree with all of these points; remember, however, that not all
> systems use GNOME (gasp! :) and making GIMP print entirely dependent
> on GNOME might limit its usefulness on other platforms.

Well, then they would have to compile a few extra packages.  What is
the big deal?   You suggest that reimplementing all of the GNOME
dependencies into gimp-print is a better approach for the sake of
"those that dont have GNOME installed"?  It seems like the benefits
outweight the problems.

> Also, CUPS (http://www.cups.org) uses PPD files successfully with
> non-PostScript printer drivers; the PPD files are used by Ghostscript
> and our image RIP to set driver-specific options which come through
> in a header prior to the raster data for each page.

Good.  Then we just need to use modified PPD files as our "repository"
for information.  Next?

> >      Our plan is to use libppd to "import" PPD files into GNOME print
> >      profiles (check http://lists.helixcode.com, gnome-print archives
> >      for the actual proposal).
> 
> I'd be careful about "importing" PPD file data into a different format.
> In our experience it causes many problems (such as syncronizing and
> updating to new drivers/PPDs), and you're better off sticking with the
> original files.  

You can just link with PPD and expose its internals trough the same
API you would access our configuration data.

Miguel.

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

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

Sven Neumann wrote:
> ...
>         4. RGB rasterizer:  This is the most interesting part: this
>            driver can rasterize the printing commands sent to a
>            printing context and generate output as an RGB buffer for
>            the entire page (as an optimization, the RGB driver works
>            in 1-inch bands).
> 
>         5. A generic PCL driver (not yet fully plugged into the
>            system).   This PCL driver is just a "derived" class from
>            the RGB rasterizer.
> 
>            This driver contains a pretty neat set of compression
>            techniques to reduce the size of the file sent to the
>            printer.
> 
>      GNOME Print on top of that can send its output currently to a
>      file (or a device) or to a Unix printer spooler.

This is one issue that has come up before: aside from maybe providing
a basic driver for PCL printers, I don't think the right "solution"
is to embed drivers in the applications.  It doesn't scale, address
"corporate" issues like accounting, etc., and can lead to all sorts
of problems for new drivers, etc.  See more below...

> * Why I believe GNOME print is a better solution than GIMP print,
>   even for the GIMP.
> ...

I agree with all of these points; remember, however, that not all
systems use GNOME (gasp! :) and making GIMP print entirely dependent
on GNOME might limit its usefulness on other platforms.

> ...
>      You will notice that some of this overlaps with existing
>      projects, like the libppd-related things.  The reason is that
>      PPD is limited to Poscript printers, and we do need a solution
>      that can be applied to more than Poscript printers.

Actually, this is not the case.  PPDs can be used even with the
current LPR and Ghostscript printing solution, which solves issues
such as changing resolution and media size on a single print queue.

Also, CUPS (http://www.cups.org) uses PPD files successfully with
non-PostScript printer drivers; the PPD files are used by Ghostscript
and our image RIP to set driver-specific options which come through
in a header prior to the raster data for each page.

>      Our plan is to use libppd to "import" PPD files into GNOME print
>      profiles (check http://lists.helixcode.com, gnome-print archives
>      for the actual proposal).

I'd be careful about "importing" PPD file data into a different format.
In our experience it causes many problems (such as syncronizing and
updating to new drivers/PPDs), and you're better off sticking with the
original files.  Also, libppd (which is the CUPS PPD interface)
provides the data structures and information needed for applications
to format output for a particular printer and display options for the
user.

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

Re: [Gimp-print-devel] First experiences with an 870

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

> > Well, 3.1.4 is probably at least as stable as the plugin in gimp 1.0
> > (version 2.0.2), and it supports far more printers at much higher
> > quality.  It could be thought of as a midlife kicker.
> 
> If it's optional, it would probably be OK.  I suppose Debian has
> a stricter idea of stability than most...

You can say that again.  Too much so for my taste.  Stable -> Stale.

Luckily, no one forces me to run the current "stable" release.

> I've thrown together a
> gimp-1.1-print Debian package, which seems to work on the machines here.
> It depends on "yada", the packaging helper which I wrote and have been
> failing to properly maintain over the last year.  I hope this won't
> cause anyone any problems...

Sounds great!

> I think Eric's work is on a gimp-printified ghostscript package; mine
> is on a gimp plugin package.  So the two should be complementary.

Yes, althought the two should probably suggest each other.

Anyway, I've been meaning to mention the fact that the scripts for
building Debian packages for Debian 2.3 are in working order.

How should we upload these packages to the sourceforge server?

Ideally, I think it would be best if we could get these packages
automatically built on the SF compile farm, however, it appears not to
have Debian available, only Caldera, Mandrake, Red Hat, Slackware, and
SuSE, AFAICT.  That's a crying shame.

Eric

Re: [Gimp-print-devel] First experiences with an 870

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

Charles Briscoe-Smith wrote:
> ...
> >    2.2.14.  Is USB likely to be faster?  I don't remember what
> >    USB's transfer rate is supposed to be.  The machine has a USB
> >    port, and, IIRC, Linux 2.2.15 does USB.
> >
> > No idea.
> 
> I downloaded the patch for 2.2.15, and it doesn't appear to have any
> USB code in it.  What 2.2.15 does add is I2O support.  Bang goes that
> idea.

The 2.2.x kernels contain a frail and mostly non-functioning USB
driver.  Look on http://www.linux-usb.org for a link to the 2.3.x
backport drivers (patches to the 2.2.x sources for the new 2.3.x
USB drivers...)

I ran into some occasional data glitches with backport drivers from
2.3.20 or so, but haven't had a chance to update my kernel to the
newest version to see if the problem is fixed; I also am using ext3fs,
and its patch doesn't apply well to 2.2.15 right now...

Anyways, IIRC USB can run up to 12Mbits/sec which puts it at least
as fast as the theoretical limit for IEEE-1284 (ECP or EPP mode,
don't remember which)  I haven't noticed any speed difference in
actual print times (printer is slower than the interface...)

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

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

[Sven N. <neu...@un...>]

Hi, 

I told Miguel de Icaza, maintainer of the gnome-print project, 
about the discussion going on regarding the future of gimp-print 
and printing in general and he asked me to forward this mail to 
you:

------- Forwarded Message
Date: Thu, 18 May 2000 09:00:42 -0400
From: Miguel de Icaza <mi...@he...>


Dear Gimp Printers,

   It has been brought to my attention that you guys have been
discussing the future of printer drivers and that you are debating
high quality printer drivers for GIMP.

   I do not know the context of your debate, but I will want to
introduce gnome-print to you guys, to consider you guys joining our
effort to provide a complete imaging solution for Unix systems.

* What is GNOME Print

    GNOME print is an imaging API modeled after the Postscript imaging
    model, that is accessible trough a Gtk+-like C API.  This imaging
    model has two major extensions: support for an alpha channel and
    anti-aliasing.

    Font rendering is achieved by loading Type1 definitions that are
    found at installation time and using those outlines to actually
    output those fonts (the fontmap.xml can be regenerated at any time
    after installation to add more fonts to GnomePrint).

    Basically, think that we have an implementation of an advanced
    "Ghostscript" in a library (without the programming language).

    The API and architecture are designed to let you plug drivers into
    the system.  Here is a list of the current drivers:

	1. Postscript.

	2. On-screen previewing (using the GnomeCanvas/Libart)

	3. Metafile driver (to record printing commands: used to
           encapsulate printer output for compound documents and for
           handling many of the user interface details: creation of
           booklets, colating, multiple-copies, reordering, two-side
           printing).

	4. RGB rasterizer:  This is the most interesting part: this
           driver can rasterize the printing commands sent to a
           printing context and generate output as an RGB buffer for
           the entire page (as an optimization, the RGB driver works
           in 1-inch bands).

	5. A generic PCL driver (not yet fully plugged into the
           system).   This PCL driver is just a "derived" class from
           the RGB rasterizer.  

	   This driver contains a pretty neat set of compression
	   techniques to reduce the size of the file sent to the
	   printer. 

     GNOME Print on top of that can send its output currently to a
     file (or a device) or to a Unix printer spooler.

* Why I believe GNOME print is a better solution than GIMP print, even
  for the GIMP.

     The GIMP print output is currently limited to printing bitmaps,
     it has no support for printing anything but that.    This limits
     its usefulness for adding other kind of information on its
     output. 

     Consider for instance adding captions, centering the image,
     printing guides, color samples, and so on. 

     If in the future GIMP print wants to add any of this, they will
     have to resort to defining an API similar to what we have in
     GNOME print, and reinvent the wheel all over again. 

     Hence, I would like to encourage people to use GNOME-print as
     your imaging API instead of your current native bitmap interface
     and to get hackers working on GNOME print to make it suit the
     imaging needs of the GIMP. 

* The future of GNOME Print

     We are working on various extensions to GNOME Print to make it a
     full solution for Unix printing, here is a list of pending tasks:

	1. Integration of Lauris Kaplinski's code in the RGBA branch
           into the main branch after GNOME 1.2 is released (on
           monday).

	2. Add the XML capabilities description for the printer to
           configure the PCL driver for the various printers we have
           out there.

	3. Add ICC support to GNOME print.

	4. Adding support for ploter-like devices by limiting the API
           of plotters.

	5. Add support for using more of the features available in the
           printer for "normal" output (ie, if the user does not use
           any advanced feature from Postscript and just outputs text,
           we can use the printer fonts if they happen to match the
           ones we have, or we can download fonts + outputing just
           text).

	6. GUI configuration tools for the various properties of the
           printers. 

     You will notice that some of this overlaps with existing
     projects, like the libppd-related things.  The reason is that PPD
     is limited to Poscript printers, and we do need a solution that
     can be applied to more than Poscript printers.

     Our plan is to use libppd to "import" PPD files into GNOME print
     profiles (check http://lists.helixcode.com, gnome-print archives
     for the actual proposal).

* How to join the development.

     Look at developer.gnome.org for the original GNOME print
     proposal to see what the ideas behind it are (this document is a
     bit outdated, but still the core concepts are still there).

     Get gnome-print from the ftp.gnome.org site.

     Look at gnome-print enabled applications: gEdit (for very simple
     output);  Gnumeric for a more complex use of the GnomePrint API;
     SodiPodi: for the ultimate user of printing functions.

Best wishes,
Miguel.




------- End of Forwarded Message

Re: [Gimp-print-devel] First experiences with an 870

[Charles Briscoe-S. <cp...@de...>]

[ As you can see, I don't reply to my email very promptly...  Sorry. ;) ]

On Fri, May 12, 2000 at 11:24:13PM -0400, Robert L Krawitz wrote:
> 
> Well, 3.1.4 is probably at least as stable as the plugin in gimp 1.0
> (version 2.0.2), and it supports far more printers at much higher
> quality.  It could be thought of as a midlife kicker.

If it's optional, it would probably be OK.  I suppose Debian has
a stricter idea of stability than most...  I've thrown together a
gimp-1.1-print Debian package, which seems to work on the machines here.
It depends on "yada", the packaging helper which I wrote and have been
failing to properly maintain over the last year.  I hope this won't
cause anyone any problems...

I think Eric's work is on a gimp-printified ghostscript package; mine
is on a gimp plugin package.  So the two should be complementary.

>    BTW, I noticed that gimp-print puts its printrc in ~/.gimp rather than
>    ~/.gimp-1.1.  Why's that?  (In preparation for gimp v1.2, perhaps?)
> 
> Not on my system, it doesn't.  It asks the gimp where to find its .rc file.

And, as if on cue, my last couple of builds have gone back to using
~/.gimp-1.1.  Spooky.

>    Something that I thought might be useful would be interpolation.
>    The dither routine could be supplied with the row before the current
>    position and the row after, and could interpolate the colour of its
>    current location from the surrounding pixels.  This might be desirable
>    when scaling up an image a lot, so that the low resolution of the original
>    image does not cause ugly pixellation in the printed output.  This would
>    have to be an option, of course, since it would only be appropriate for
>    some kinds of images, like photos.
> 
> I've thought about this.  It would require a major change in the
> architecture -- give the dithering routine a line, and have the
> dithering routine call back into the driver.  That's a good
> architecture, but it would take a fair bit of work.  Besides, it would
> probably be very slow.  I don't know if Raph's code requires something
> like that; if it did, it would be a good impetus for it.

I had imagined the interpolator to be a separate module, in the same
way that the ditherers are.  Then the dithering code would pass the two
lines bracketing its current position to the interpolator, and get back
a line interpolated between them.  That assumes we're not going to use
more than the four pixels surrounding any one point to determine the
value of a point in between.  Maybe the more advanced interpolation
algorithms use more surrounding points, in which case that wouldn't work.

For a simple linear interpolation between the four pixels surrounding the
current point, it shouldn't need much of an architectural change, IMO.
However, given the long-term goals you've described for gimp-print,
this should probably not be done in the code we're working on here.

>    > I have the same problem (kernel 2.2.10).  What kernel are you running?
> 
>    2.2.14.  Is USB likely to be faster?  I don't remember what USB's transfer
>    rate is supposed to be.  The machine has a USB port, and, IIRC, Linux
>    2.2.15 does USB.
> 
> No idea.

I downloaded the patch for 2.2.15, and it doesn't appear to have any USB
code in it.  What 2.2.15 does add is I2O support.  Bang goes that idea.

>    > That's an attempt to correct for the starting vertical position thing
>    > you noted below.  I don't have that quite right.
> 
>    This patch seems to fix it; the comment says how I think it does so:
> 
> It's also obsolete (or will be, as soon as I check in my latest
> stuff).  I've figured out how to print all the way to the top edge and
> to about the bottom 5/16".  I could probably even closer if I tried.
> I've been spending all evening testing it and writing yet more test
> cases.  It's painful.  It may not work absolutely correctly for 360
> dpi and microweave (particularly the bottom of the page).  I'll
> probably check it in tonight even if it isn't 100% tested; it's useful
> enough so it's worth getting out there.  The Ghostscript users will be
> very happy about this.
> 
>    I've spent a day or two so far teasing apart the weave code, and I'm
>    *pretty* sure I know more about how it works than when I started...
>    It's hairy stuff, though.  It's going to take a while longer before I
>    understand it.
> 
> It's going to be even worse after tonight.

(Actually, I could understand those changes quite easily.  Much of the
rest of the code is still a mystery...)

Hmm.  The reason I was studying the weave code was because I was going
to try to modify the weave pattern to make it print closer to the edges
of the paper.  Since you've already done this, though, there's little
reason for me to work on it too.  ;)

> There are a few more parameters in the stuff I'm about to check in.
> Those should be fairly obvious.  The separationrows thing probably
> isn't needed in softweave, but I don't have a 1520 or 3000 handy to
> test, so I haven't enabled softweave for it.

We have a 3000, so I could try testing stuff on it if you like.  (But as
you might've noticed, my response time it not guaranteed to be fast...)
It's hooked up to my dad's Win95 box, but that shouldn't cause too
many problems.

> Well, except for the phantom row issue.  Also, the stuff that lets me
> print to the edge of the page needed some changes to the weave pattern
> in those areas of the page in order to work.

Indeed.  This is what I was planning to change, too.

I noticed that your change to the weave pattern was much simpler than the
way I wanted to do it.  It basically cuts off the top and bottom jets*sep
rows and print them in a "naive" weave pattern, which unfortunately
causes some patterning in that section of the print (on the 870 it's
only really noticeable in fairly smooth areas like clear blue sky).
The few passes next to that section don't use all the nozzles on the
print head.  If you took all the print lines which could be printed in
the normal weave pattern and transferred them from the "modified" passes
to the "normal" passes, you'd have approximately what I was planning,
which would probably reduce the patterning.

I've tried it, though, and I wasn't able to get it working.  This seems
to be because of the assumptions that the softweave code makes.
Specifically, it assumes that the last row of each pass occurs later
than the last row of the previous pass.  I think my code didn't work
because it violated that assumption.  (It may also assume that there are
no empty passes, but I'm not sure.)  If I ever work out how all those
complicated formulae generate that nice weave pattern, I might be in a
position to fix this...  ;)

> I won't put that one in tonight, but it's a good idea.  What's
> SIGNULL, though?  I don't think it's POSIX.  Actually, you should get
> a Sourceforge account and I'll add you as a developer.

Sorry about the SIGNULL.  I put that there temporarily while I wrote the
code intending to check it against the libc docs later.  When I checked,
I found that signal number 0 doesn't have a constant defined for it, so I
replaced SIGNULL with the literal 0.  I forgot to regenerate the patch,
though.  Signal 0 is a signal that doesn't affect the target process
at all; it just gives an error response from kill() if the process
doesn't exist.  Its purpose is to enable you to see whether a process
is still alive.  If it's no longer documented, there might be another
way to do this now.  Actually I think I first read about it on SunOS,
so maybe it's a SunOSism.

> If you're willing to get a Sourceforge account, let me add you as a
> developer, and make the change on the other drivers (ps, pcl, and
> Canon), go ahead.  It's not my favorite idea, but I must admit that it
> would save some headaches in some cases.

I've joined sourceforge, with username "cpbs".  I'll take a look at the
other drivers, and see if I can do anything with them.  I doubt the PS
driver will need any changes, since the postscript interpreter should
clip to the printer's printable area.  I suspect PCL printers also clip.
I'm fairly sure the Laserjet4 clips PCL commands: some years ago, when
the LJ4 with its 600dpi was new, I hacked the (binary) laserjet driver
of PageStream (an Atari DTP program) to do 600dpi output (and to do RLE
compression when useful), and I think I saw the printer do clipping then.
I don't know about Cannon.

Cheers,

-- 
Charles Briscoe-Smith             <URL:http://www.debian.org/%7Ecpbs/>
PGP2:  1024/B35EE811  74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2
"You think that's air you're breathing now?" -- Morpheus, "The Matrix"

Re: [Gimp-print-devel] Latest results

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

Thomas Tonino wrote:

> > Thomas, could you play around with your new matrix some more?  It's
> > not in, because having only one matrix caused problems, but it does
> > look promising.  It really bloats the executable, though.
> 
> I have a number of things I'm trying.

It turns out the things that I'm trying don't work. While CMY dither
works fine the transition to K just doesn't work out - even if I use
rand() instead of a matrix.

This led me to believe that the current K generation needs error
diffusion to give a decent result. I changed the following piece:

              else if (kdarkness < ub) /* Probabilistic */
                {
                 /*
                  * Calculate how much black we are going to shuffle
away
                  */
                  if ( kdarkness >= lb )
                    rk = (kdarkness - lb) * ( ok / rb);
                  else
                    rk = 0;
                  if ( rk > ok )
                    rk = ok;
                  /*
                   * Pick a range point, depending upon which dither
                   * method we're using
                   */
                  if ((d->dither_type & ~D_ADAPTIVE_BASE) == D_FLOYD)
                    ditherbit = ((xrand() & 0xffff000) >> 12);
                  else
                    ditherbit = (DITHERPOINT(d, x, row, 4));
                  ditherbit = ditherbit * rb / 65536;
                  if (rb == 0 || (ditherbit < (kdarkness - lb)))
                    bk = ok;
                  else
                    bk = 0;

The calculation of rk is new. rk is the amount of black that will on
average be moved to bk by the DITHERPOINT macro.

This rk (the amount to be generated) is then subtracted from cmy, just
as bk (the amount that was generated) was originally:

          if (rk > 0)
            {
              c -= (d->k_clevel * rk) >> 6;
              m -= (d->k_mlevel * rk) >> 6;
              y -= (d->k_ylevel * rk) >> 6;


I have to set density a bit lower (to 0.9) and still the density of
black seems too high.  I tried first with dither_set_black_lower(dither,
.1 / bits) in print-escp2.c because that shows problems rather clearly,
but with the above changes, the 'green problem' is fixed.

Black does build up rather quickly though: dark colors are too dark. But
compared to older pictures, the absence of the green problem makes
everything look much crisper on my lowly 4 color printer.

Going back to .4 for dither_set_black_lower shows a problem: from light
to dark, first CMY builds up. At higher density, K also starts to build
p. Suddenly, CMY drops off to 0 while K is not up to maximum yet. So
there definitely is a problem with the value of rk: maybe it's off by a
factor of 65536?

The result for photos still looks okay even if dark colors are a bit
muted. But in theory, this change looks like an improvement to me.

I do not have good insight currently in what kdarkness, ok, and others
exactly do. I do know that what I see for dither_set_black_lower = 0.4
demonstrates my code is wrong. I'd like to achieve something along the
following lines:


/* if c + m + y is more than the paper can absorb, we determine which
portion to take off*/
coverage = c + m + y;
if ( coverage > maxcoverage )
   overcover = maxcoverage - coverage
else
   overcover = 0

/* find out the K component of the color to be printed */
if ( c < m )
  kcomponent = c;
else
  kcomponent = m;
if ( kcomponent > y )
  kcomponent = y;

/* if kcomponent = max, we can make blacktoprint max and thus no CMY
needs to be printed */
blacktoprint = blackcurve(kcomponent);

if ( overcover/3 > blacktoprint )
  blacktoprint = overcover/3;

/* no CMY will be printed if eff_x_value(max) equals max */
ctoprint = c - eff_c_value(blacktoprint);
mtoprint = m - eff_m_value(blacktoprint);
ytoprint = y - eff_y_value(blacktoprint);

where eff_x_value might be one function if we let the 'greenishness
problem' be covered by using black more aggerssively or using color
management.

It may even be possible to make this work with the right combination of
the current variables. It just seems that using the binary dither result
to adjust analogue input values is not a good idea for ordered dither,
and it may not be a good idea at all.

It's late now. The new matrixc will be ready tomorrow morning, but I
doubt it will make a significant difference if rand() causes the same
problems as re-using the matrix. Maybe K doesn't register exactly with
CMY or so - in any case, K buildup in the old code looks very clustery.


Thomas

Re: [Gimp-print-devel] Latest results

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

Robert L Krawitz wrote:

> Thomas, could you play around with your new matrix some more?  It's
> not in, because having only one matrix caused problems, but it does
> look promising.  It really bloats the executable, though.

I have a number of things I'm trying.

The simplest is to change the ditherpoint call that does the black
decision to use not x and row but x+50 and/or row+50. Given that the
matrix is not very correlated with itself, this should give okay
results.

The second is that I'm generting a new matrix now. It has somewhat
reduced noise, but more interesting may be the change in selected
initial points. The current matrix has starting points selected for
minimum autocorrelation when shifted 1/2 H or V, the new matrix will
shoot for 1/3 or 2/3 H and V. This gives 9 uses for a single matrix:
enough for cCmMyYkK and yet another independent use.

I could also try making another, smaller matrix, for the decision to
'print black': maybe something as small as 31 on a side or as large as
151.

The last option would be to generate a number of matrices to be used for
a single purpose each. I'm afraid this will give huge bloat.

I think I'll try the options in the above order. How do people feel
about these large matrices appearing in CVS? If no one objects, I'll put
the new matrix in when it is ready and produces useful results.

Robert, do you think 199 x 199 is big enough for a release version or
would you prefer 251 x 251 or 257 x 257 ? That would make full of the 16
bits internal resolution at least.

As for the sharpening that is inherent in Floyd-Steinberg: I didn't
think about that myself, but read about it in one of Ulichney's papers.
But I think I understand, and maybe I can even explain:

Error diffusion does the following:

Input -> Approximation -> Simulation -> Delay -> Subtract from next
input values.

Essentially, this is what error diffusion does: except FS does things a
little more abstract and talks about 'error': instead of simulating and
then subtracting from other input values, FS takes a shortcut and
subtracts a value immediately from _coming_ input values if a dot is
printed.

In any case, the approximated version (which is much like the original)
is delayed and blurred (by diffusing into other cells) as it is
subtracted from the input. And what happens if a blurred version of X is
subtracted from the original X: X is sharpened by making the low
frequency components weaker. The process is also called 'unsharp mask'.


Thomas

[Gimp-print-devel] Latest results

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

My latest test print on the 870 is much better than the previous one.
Almost all of the artifacts have entirely gone away.  There's the
slightest of reddish casts in some of the gray midtones, but nothing
like last time.  It looks much more like a true photograph at this
point.  I'd say an 8x10 is very close to a photographic print from 35
mm (with certain exceptions), but it wouldn't match up to a print from
medium format.

I'd like people with other variable dot size printers to try this.  I
think it will improve printing on all such printers.

There may be a slight regression on the EX.  There's definitely a bit
of a pink (magenta?) cast.  Beyond that it's hard to tell for sure.

If you use 1440x720 dpi highest quality on the new printers, you may
find you need to boost density slightly.  The general consensus has
been that 1.5 is the correct density for the ESP 870; I found I needed
1.7.  You may not need to use this mode.  I found that my test
patterns showed banding with normal 1440x720 that went away at highest
quality (using Epson coated paper), but my test prints of the PDI
target showed very little banding (on Epson photo paper) on either
setting, although highest quality was better under very close
inspection.

Thomas, could you play around with your new matrix some more?  It's
not in, because having only one matrix caused problems, but it does
look promising.  It really bloats the executable, though.

Re: [Gimp-print-devel] Printing & KDE

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

Waldo Bastian wrote:
> ...
> I guess that CUPS basically uses ghostscript in some fashion as a
> kind of printer-driver. That makes the following chain:
> 
> 1) printer driver  (ghostscript)
> 2) transport layer (CUPS)
> 3) abstraction layer (sysAPS)
> 4) KDE (?)

Actually, it's more like:

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

For the current CUPS release, there are two possible "raster paths",
either using Ghostscript or our image RIP, which send raster data
to the printer driver, which sends the print data to a backend
process that talks to the parallel, serial, USB, IR, etc. ports or
one of several network protocols.

IPP is the transport layer.

CUPS is the printing system/spooler that decides when to print and
what filters are needed.

The filters are found from a MIME database that defined types and
filters available to the system.  For a typical PostScript job to
a non-PS printer, you'll run "pstops" and "pstoraster".  "pstops"
inserts the printer options (resolution, media size, type, etc.)
and "pstoraster" is Ghostscript with the CUPS raster driver (only)

The driver can actually be multiple filters, e.g. one to print
text fast, and one to do raster graphics, and one to do HP-GL/2,
etc.  The basic driver just needs to read pages of raster data
from the upstream filters and generate the appropriate printer
data.

> ...
> The disadvantage of so many layers is that new, more advanced
> features require adaptions in multiple layers before you can use
> them at the application level.

That's why you design your interfaces to be extensible. :)

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

[Gimp-print-devel] bug when changing printer in print-3.1.3

[Joern C. <jc...@Ge...>]

Hi!

I'm not sure if this was covered by the error report I sent some time ago...

I have a bunch of PostScript printers, that are configured via PPDs.
When I select a printer for the first time, all printer specific things
change, e.g. the list of media sizes, types and sources are imported from
the PPD. When I select another printer, these lists (i.e. the corresponding
cycle buttons) don't change. I tried to track this in the source, but
GTK is just too complex for me. I guess, calling gimp_plist_callback() at
the right moment might to the trick, but I was unable to find an appropriate
place for this.

-- 
----------------------------------------------------------------------------
 Joern Clausen                                                 Abteilung IT
 jc...@Ge...                       Biologie / BioVI Genetik
 0521/106-4826                                       Universitaet Bielefeld

[Gimp-print-devel] Canon 8200 activated for testing

[Andy T. <th...@ph...>]

Stephan Buchert wrote:

> Hi,
>
> I have a Canon BJC8200 printer, featuring 6 colors, 1200x1200 DpI^2,
> microfine droplet technology (=variable drop sizes?), and support for
> a new type of paper, Photo Paper Pro.
>
> I would be happy to test the gimp-print plugin with my printer.
>
> So far I can produce acceptable prints using ghostscript with it's
> uniprint device driver. For this purpose I made new uniprint control
> files (*.upp) for the BJC8200. They are available at
>
> http://www.stelab.nagoya-u.ac.jp/~scb/uniprint
>
> and are also included in (Aladin) ghostscript >=6.21.
>
> The gimp prints well with my printer when using ghostscript and the
> right *.upp files. When looking at the source code of the gimp print
> plugin (version 3.1.4), I noticed that support for printing directly
> (not via ghostscript) to Canon printers is being prepared, but the
> BJC8200 model doesn't seem to be working yet. As said above, I could
> assist in the development as tester.

So welcome to the list :-)

I've just activated the 8200 for testing, so go and give it a try - I haven't
yet looked into your .upp files so it might be possible it doesn't work at
all. So keep a finger at the printers power switch...

Best wishes,
Andy.


--
Andy Thaller
TU Muenchen, Physikdepartment E11       Tel: ++49 (0)89 289 12860
James Franck Str.                       Fax: ++49 (0)89 289 12842
85748 Garching   //  Germany            email:  th...@ph...

[Gimp-print-devel] Printing & KDE

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

Hiya,

I was alerted that you guys were looking for KDE people. Well, I am a KDE 
person :-) I have no specific printing knowledge, so be gentle with me.

There isn't too much to tell about printing & KDE unfortunately. There is 
little active development in this area at the moment. The basic idea is that 
printing is done trough Qt which generates postscript. /etc/printcap is 
parsed to generate a list of printer you can choose from and the user can 
select the page size.

I have been looking around a bit tonight at CUPS and Corel's sysAPS (System 
and Application Print Services). Both look promising and should fit nicely 
together. 

I guess that CUPS basically uses ghostscript in some fashion as a kind of 
printer-driver. That makes the following chain:

1) printer driver  (ghostscript) 
2) transport layer (CUPS)
3) abstraction layer (sysAPS)
4) KDE (?)

The advantage of sysAPS for KDE is that we don't have to write support for 
different transport layers. Especially if GNOME uses sysAPS as well, we can 
achieve a high level of compatility between the two desktops in that area.
I have no idea what the plans of GNOME are wrt printing though.

The disadvantage of so many layers is that new, more advanced features 
require adaptions in multiple layers before you can use them at the 
application level.

Cheers,
Waldo

[Gimp-print-devel] More high end stuff

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

I found a few things going wrong that led to excessive grain on the
870:

1) The code to decide what dot size to use was looking at the density
   rather than just the color to be printed.  This is probably good at
   very high densities, but it's not so good in regions where there's
   a small amount of one color (read: cyan) in a field of something
   else (read: yellow).  The upshot was that large cyan dots (and
   possibly even small dark cyan dots) were being printed in magenta
   or yellow with even a slight mix of cyan.

2) Similarly (but not identically), the black code was just making a
   binary on/off decision, and either printed the full value of the
   black or nothing.  Again, that led to large black dots.  I've
   changed that to simply slide between k_lower and k_upper, so that
   small amounts of black ink are printed as small dots rather than
   fewer large dots.

3) The adaptive dithers were omitting all ink in some regions that
   they should have been printing.  This is quite visible if you know
   what to look for.

4) The k_lower value was too high in variable dot size printing, now
   that I fixed (2).

5) The black equivalent values in the Epson code were too high (1.5).
   That resulted in too little color ink being printed, which resulted
   in grainy dark grays.  Setting it to 1.0 helps, although it doesn't
   entirely solve the problem.

6) I eliminated use of the largest dot size of the light ink.  This is
   a bit tricky.  It was causing problems (fairly sharp transitions)
   in darker regions of mixed colors, because the transition band
   between light and dark inks was too narrow.  I experimented with a
   few things, and this seems to be the best compromise.

The yellow cast seems to be entirely gone.  There might be a VERY
slight blue or cyan cast to the grays right now, less than one point.

I haven't hooked up the EX yet to try it.  Nor, for that matter, have
I tried printing a real image yet, just my test shot.  I'm going to
push the PDI target through overnight (doubtless at the cost of a few
dollars worth of ink) at 1440x720 highest quality (which seems to want
me to set the density to 1.7 rather than 1.5, probably because of
imperfect head alignment -- good ghod, this can be an expensive hobby)
to see what happens.

Yawn.

Jean-Marc, my apologies.  I know I promised I wouldn't touch this for
a while, but I couldn't help myself...

-- 
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] What direction should we be headed?

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

   Date: Wed, 17 May 2000 21:23:46 -0400
   From: Michael Sweet <mi...@ea...>

   FWIW, none of the printer manufacturers I talk to are willing to
   open source drivers for their entry-level printers; they talk of
   "giving away secrets to their competitors", while we have to
   shake our heads and say "it isn't so!" since we've seen it all
   and *know* it wouldn't make a difference...

I can see their point as far as dither algorithms per se are
concerned.  As far as the programming specs, this is, of course, sheer
nonsense.  All that happens is that we waste some time reverse
engineering their commands.

Epson's been rather more cooperative than most (at least, that's my
opinion).  So maybe Epson will be able to sell more printers into the
Linux market, even if their software folks won't help.

   > Cisco Enterprise Print System:
   >  A set of tools for making the adminstration and support of large
   >  number of printers dramatically easier

   But still based on LPD; they've volunteered to port a lot of their
   stuff to CUPS since it supports IPP and other network stuff they
   like.

LPD must die.  No two ways about it.

   > Open Source Printing:
   >   VA and HP are driving a partnership with the Open Source
   >   community to create great Open Source printing

   for PostScript laser printers from HP, although the group that is
   developing PPD-based filters (using the CUPS code, BTW) is also
   trying to support other vendors' PostScript printers, too...

I suspected as much, given that their entry-level folks have been
completely unwilling to release specs on their printers to us.  Of
course, true PostScript printers are also relatively straightforward
to support.

   > Application Print Services Library:
   >   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.

   This is an attempt at supporting multiple printing systems, and using
   the features available in all of them.  Some of the comments I've
   heard indicate that the API is not as easy to use as some would
   like...

At least one of their mailing lists is essentially dead.  I see almost
no traffic on it.

Notice that one thing that none of these projects is doing is working
on improving print quality on low end printers -- the bread and butter
of the desktop.  We seem to be the only project looking at that very
hard.

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