gimp-print-devel

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: 19 May 2000 19:06:17 -0400

   > 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 was already expecting that.  From previous advise from Theo de Raadt
   on a similar but different topic.  

Both Mike and Theo have substantial experience in their areas of
expertise, and shouldn't be dismissed out of hand.

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

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

That's exactly his point -- those problems HAVE arrived, and they
exist in the here and now, and he's actually been tackling them.

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

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

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

I assume DSO = Dynamic Shared Object or something like that.

Eric

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

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

> 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 was already expecting that.  From previous advise from Theo de Raadt
on a similar but different topic.  

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

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

> As for scalability, adding DSOs doesn't mean your solution is
> scalable.  How many DSOs are required to implement N drivers?  N
> DSOs?  And what about non-GNOME applications?  What do *those*
> applications do for printing?!?

You lost me with the acronym.  I cant follow this at all.

Miguel;.

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

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

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

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

And I think your work fits nicely in GnomePrint.

I am glad to read your message again Robert.

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

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

I am sorry if I came out as saying that we had the ultimate solution.
We dont.  The Generic PCL driver is just a technology demostration
that our rasterization system works, and it is obviously our choice as
the "foundation" for continued development.

Here is where I believe both projects should unify.  Again, I am sorry
if people got the wrong impression.  I was just listing the different
kind of "outputs" supported by gnome-print.

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

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

But right now, you can see real apps doing real printing (Gnumeric,
SodiPodi, GtkHTML, Evolution are the most important ones)

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

What is handled pretty well in this case?

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

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

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

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

Great.  We can fit this.  

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

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

At least I dont think I said that recently, as I had a long
conversation with Chema, who enlightened me about this topics.  Then
Tuomas and someone else at the office insisted in talking to me for
two hours about the the levels of cyan.

Anyways, I doubt a lot that I had said such thing.  And if I did, then
I correct myself.

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

I do not follow this, but it is ok.

Miguel.

Re: [Gimp-print-devel] Ghostscript driver

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

> By the time we're down at that level, we may not have access to the
> user's home directory (if the user even has one on the system where
> this is running).  We also don't know who the user is at this point.
> Everything's been handed off to the print system by now.

Ah yes, of course.  Jetlag must be getting the better of me.

Eric

Re: [Gimp-print-devel] Ghostscript driver

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

   Date: Fri, 19 May 2000 22:41:08 +0200 (MET DST)
   From: Andy Thaller <And...@Ph...>

   But you still need a method to pass options to the ghostscript driver.
   An integer value for the printer model is in no way sufficient so this has
   to be changed.

I agree.  This must go.

(...and everyone looks in rlk's general direction, and a faint
e-p-s-o-n is heard in the background...)

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

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

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

Re: [Gimp-print-devel] Ghostscript driver

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

   From: sh...@al...
   Date: Sat, 20 May 2000 04:58:17 +0900

   What I think should be done is to write a simple shell script which can
   parse the user's saved printer configuration and call ghostscript with
   the appropriate options.  This shell script can be used as an input
   filter in the printcap file. Whether the options are numerical or string
   is largely irrelevant then, since the user would not need to see them.

By the time we're down at that level, we may not have access to the
user's home directory (if the user even has one on the system where
this is running).  We also don't know who the user is at this point.
Everything's been handed off to the print system by now.

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

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

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

   Date: Fri, 19 May 2000 20:54:56 +0200
   From: Thomas Tonino <tt...@bi...>

   Further remark: the old ordered dither now seems useless because of its
   autocorrelation. Depending on density in the grey wedge, C, M or Y hads
   the greates tendency to disappear under K, leading to a rainbow-effect
   grey wedge.

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

   I reinstated the old kdarkness generation:

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

   Instead of (ok - lb) squared I use this as direct black value, so we
   start producing appreciable amounts of black early on.

If you want to do that, you should be using 

   ! 		  bk = (ok - lb) * d->density / (ub - lb);

rather than

   ! 		  bk = (ok - lb) * 65535 / (ub - lb);

Otherwise you'll go massively overboard on the black, and it will vary
depending upon which resolution you use.

   *** 1600,1608 ****

	     if (bk > 0)
	       {
   ! 	      c -= (d->k_clevel * bk) >> 6;
   ! 	      m -= (d->k_mlevel * bk) >> 6;
   ! 	      y -= (d->k_ylevel * bk) >> 6;
		 if (c < 0)
		   c = 0;
		 if (m < 0)
   --- 1608,1617 ----

	     if (bk > 0)
	       {
   ! 	      bk = bk * bk / 65536;
   ! 	      c -= (d->k_clevel * bk) /128;
   ! 	      m -= (d->k_mlevel * bk) /128;
   ! 	      y -= (d->k_ylevel * bk) /128;
		 if (c < 0)
		   c = 0;
		 if (m < 0)
   ***************

OK, you have two problems here: first of all bk needs to be unsigned
for this to work, and secondly you've changed the divisor from 64 to
128.

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

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

On Thu, May 18, 2000 at 09:47:44PM -0400, Robert L Krawitz wrote:
>    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.

Yes.  I'll look at it again when I have the time.  (I'm putting together
an Exif decoder at the moment...  I want to be able to pick thumbnails
and timestamps out of camera-generated image headers.  There might also
be some colour correction stuff in there too.)

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

;)

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

There's another way to do that.  You've probably noticed that if you turn
the printer off while it still has paper in it, it'll eject the paper.
Apparently, though, (at least with a Photo 700) when you turn it on again,
it'll think it still has paper in the print path and will, if asked,
print a whole page onto the platten.

> I've added you.

Thanks.  To start off, I'll try to commit my "cancel" patch sometime this
weekend.  Hopefully without committing all my other random hacks too. ;)

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

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

On Fri, May 19, 2000 at 08:37:20AM +0900, sh...@al... wrote:
> > 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.

OTOH, a stable Debian release is closer to being bug-free than anything
else I've seen.  Testing takes time.

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

Agreed. ;)

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

Certainly they should mention one another in their extended descriptions,
but is either one useful if you've already installed the other?  Maybe so:
you'd want the gimp plugin version for extra control when printing photos,
and the gs version for getting decent output from abiword and the like.
But I'd still think twice before having them suggest each other.

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

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

   Date: Sat, 20 May 2000 03:06:56 +0200 (CEST)
   From: Lauris Kaplinski <la...@ar...>

   There is no such thing as GNOME dependency (aside packages :).

Which you really shouldn't brush off like that.  It's quite a lot of
stuff.  My /opt/gnome (October) is 80 MB, and what looks like about 50
packages.
								  
								  There are
   dependencies to several different free libraries, which happen to be
   distributed as a part of GNOME. And some libraries has every program to
   use, if it does not want to reimplement all things under the sun...

Fine, and what do THOSE libraries depend on?  glib is actually
reasonably self contained; most of the others depend on a lot of other
stuff.  Now we start to get into DLL hell.

   Once gnome-print stabilizes enough, it would be meaningful to
   separate it into GUI and backend parts. GUI part needs and will
   always be needing libgnomeui for print-preview canvas, dialogs etc.
   Non-gui base requirements are only Gtk+ (object system) and libart
   (drawing primitives). Not very much, I think...

There's nothing wrong with the GUI stuff (and the printing API for
GNOME programs) requiring the GNOME libraries.  That's completely
appropriate.  It's the back end stuff that really needs to be done
completely independently of any UI toolkit, desktop, etc.

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

Sorry, I don't buy it.  KDE users won't do it, nor will Motif users,
nor will CDE users.  Nor, for that matter, will servers.  Servers
won't even have X installed on them.  If they need to be running X in
order to handle printing, then we're just implementing Windows all
over again, where the GUI permeates everything (and destabilizes and
bloats it).  The back end printing system *had better* be completely
independent of any particular UI choices (or lack thereof).

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

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

-- 
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] Another dark tint improvement

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

   Date: Fri, 19 May 2000 23:06:07 +0200
   From: Thomas Tonino <tt...@bi...>

   I believe I found the cause of the wedge problem: the value of bk gets
   too high. The extra if in the following snippet makes the wedge look
   beautiful. Photos come out very nicely as well, both in ordered dither
   (199*199 matrix) and Floyd-Steinberg. Still using 0.1 and 0.699 for
   dither_set_black_lower and -_upper, respectively.

	     if (bk > 0)
	       {
		 if ( bk >= 32000 )
		   bk = 32000;
		 bk = bk * bk / 65536;
		 c -= (d->k_clevel * bk) /128;
		 m -= (d->k_mlevel * bk) /128;
		 y -= (d->k_ylevel * bk) /128;

I thought that the problem was that bk was declared int, but even
declaring unsigned didn't help.  I think what you really want is to
cap it at d->density.

   I'm wondering if we cannot make processing more efficient by changing
   the:

   if (black != NULL)

   near the beginning of the main loop in

   if ((black != NULL) & (k != 0))

   This would skip the black generating process for bright colors and
   white.

That won't work if error diffusion is used.  It might work if ordered
dithering is used.

In any event, this didn't work at all for me.  Pull down
http://www.tiac.net/users/rlk/colors.tif and print that.  There is
very severe excess black.

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

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

On Fri, 19 May 2000, Michael Sweet wrote:

> 
> 3. Building drivers into GNOME applications does not help non-
>    GNOME applications.

There is no such thing as GNOME dependency (aside packages :). There are
dependencies to several different free libraries, which happen to be
distributed as a part of GNOME. And some libraries has every program to
use, if it does not want to reimplement all things under the sun...

Once gnome-print stabilizes enough, it would be meaningful to separate it
into GUI and backend parts. GUI part needs and will always be needing
libgnomeui for print-preview canvas, dialogs etc.
Non-gui base requirements are only Gtk+ (object system) and libart
(drawing primitives). Not very much, I think...

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

Lauris

Re: [Gimp-print-devel] Ghostscript driver

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

> But you still need a method to pass options to the ghostscript driver.
> An integer value for the printer model is in no way sufficient so this has
> to be changed.

I don't follow your logic.  Is there some shortage of integers that I'm
not aware of?

> The ghostscript uniprint driver uses those .upp files - I cannot judge at
> the moment if this would be an applicaple way to set the driver options
> but perhaps it'b be an alternative.

No, no, no.  I'm not trying to propose something new.  We already have
a file that contains the driver options.  ~/.gimp-1.1/printrc  Why do
we need more than that?  Maybe the location needs to change as we move
away from the Gimp, but other than that, it should be sufficient.

> > In addition to this, we would probably also need a standalone GUI/ncurses/
> > commandline printer configurator, for those people who don't want to run
> > the Gimp/X11/interactively, but that doesn't sound that hard to do.
> 
> Shouldn't we leave this to the distributors? SuSE comes with a more or
> less nice printer configuration tool and AFAIK RedHat has one too.

What?  I've never used those tools, but my understanding was that they merely
configured the printcap file.  Since this is something completely different,
I don't see how these programs are relevant.

> Of course my last two remarks don't aply if you meant the case where you
> call gs from the commandline (or any GUI watever) and send raw printer
> data to the spooling system.

I think very few people will be calling gs directly from the command line.
Such people would by definition be experts and can manage to figure out the
correct options for themselves.

> This would have the same implications as
> mentioned previously on this list however. All this lpd/gs stuff
> with its stupid lack of passing options really sucks, always did so, but
> it's spread too far so we have to find a smooth solution...

I think a simple script which can read the printrc and translate that into
options for gs is pretty smooth.

Eric

[Gimp-print-devel] Another dark tint improvement

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

I believe I found the cause of the wedge problem: the value of bk gets
too high. The extra if in the following snippet makes the wedge look
beautiful. Photos come out very nicely as well, both in ordered dither
(199*199 matrix) and Floyd-Steinberg. Still using 0.1 and 0.699 for
dither_set_black_lower and -_upper, respectively.

	  if (bk > 0)
	    {
	      if ( bk >= 32000 )
	        bk = 32000;
	      bk = bk * bk / 65536;
	      c -= (d->k_clevel * bk) /128;
	      m -= (d->k_mlevel * bk) /128;
	      y -= (d->k_ylevel * bk) /128;


I'm wondering if we cannot make processing more efficient by changing
the:

if (black != NULL)

near the beginning of the main loop in

if ((black != NULL) & (k != 0))

This would skip the black generating process for bright colors and
white.


I'll put the latest patched version in print/Matgen. I'm not too happy
about the 32000 limit for bk above, but it works. 64K did have some
effect, but not enough.


Thomas

Re: [Gimp-print-devel] Ghostscript driver

[Andy T. <And...@Ph...>]

On Sat, 20 May 2000 sh...@al... wrote:

> <gripe>
> Andy, is it really necessary to send HTML to the mailing list when plain
> text will do fine?  I find it really annoying when mh spawns lynx to read
> a web page that's been mailed to me and there's nothing but text on it.
> </gripe>

Sorry, happened unintentionally, I'll try to turn it off... 

> > I've looked over the ghostscript driver part in order to see how the canon
> > driver could be added. The gs driver uses the option "Model" being an integer
> > value. How about changing this to string and check it against printers->drive
> > r
> > (which is unique for any printer model as I get it).
> 
> I've been thinking about this and I'm not sure that that's the best way to
> go.

But you still need a method to pass options to the ghostscript driver.
An integer value for the printer model is in no way sufficient so this has
to be changed.

> What I think should be done is to write a simple shell script which can
> parse the user's saved printer configuration and call ghostscript with
> the appropriate options.  This shell script can be used as an input
> filter in the printcap file. Whether the options are numerical or string
> is largely irrelevant then, since the user would not need to see them.

The ghostscript uniprint driver uses those .upp files - I cannot judge at
the moment if this would be an applicaple way to set the driver options
but perhaps it'b be an alternative. Those files could do the finetuning
for a certain combination of printer model, resolution and output media.
Of course this would lead to many many such files but I don't really see
any other chance with ghostscript (especially when used from apsfilter or
alike).

> In addition to this, we would probably also need a standalone GUI/ncurses/
> commandline printer configurator, for those people who don't want to run
> the Gimp/X11/interactively, but that doesn't sound that hard to do.

Shouldn't we leave this to the distributors? SuSE comes with a more or
less nice printer configuration tool and AFAIK RedHat has one too.

Of course my last two remarks don't aply if you meant the case where you
call gs from the commandline (or any GUI watever) and send raw printer
data to the spooling system. This would have the same implications as
mentioned previously on this list however. All this lpd/gs stuff
with its stupid lack of passing options really sucks, always did so, but
it's spread too far so we have to find a smooth solution...

> Unfortunately, I have no time for the next two weeks.

two months in my case ;-)

Andy.

[Gimp-print-devel] SF support request for Debian on Compile Farm

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

BTW, I filed support request 101872 at SourceForge asking that Debian
be added to the compile farm.

Eric

Re: [Gimp-print-devel] Ghostscript driver

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

<gripe>
Andy, is it really necessary to send HTML to the mailing list when plain
text will do fine?  I find it really annoying when mh spawns lynx to read
a web page that's been mailed to me and there's nothing but text on it.
</gripe>

> I've looked over the ghostscript driver part in order to see how the canon
> driver could be added. The gs driver uses the option "Model" being an integer
> value. How about changing this to string and check it against printers->drive
> r
> (which is unique for any printer model as I get it).

I've been thinking about this and I'm not sure that that's the best way to
go.

What I think should be done is to write a simple shell script which can
parse the user's saved printer configuration and call ghostscript with
the appropriate options.  This shell script can be used as an input
filter in the printcap file. Whether the options are numerical or string
is largely irrelevant then, since the user would not need to see them.

In addition to this, we would probably also need a standalone GUI/ncurses/
commandline printer configurator, for those people who don't want to run
the Gimp/X11/interactively, but that doesn't sound that hard to do.

Unfortunately, I have no time for the next two weeks.

Eric

[Gimp-print-devel] Black generation, continued

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

I tried Roberts latest CVS updates and these were what I Was trying to
achieve, but didn't succeed in. I got addicted to the use more more
black though, so I adjusted things around a little. Things look fine for
photos: better than they ever did, if using the large dither matrix.
There are problems though with overflows. Floyd-Steinberg can look like
the cartridge has been dripping milk in dark areas and a white-to-black
wedge shows definite artefacts when black gets dense: black suddenly
gets switched out to reappear later with ordered dither. Floyd is worse:
a white line appears in the dark portion of the bar, and the line gets
wider down the print. Probably an overflow effect as well. All this
tested with 0.1 for dither_set_black_lower and .699 for
dither_set_black_upper in print-escp2.c. dither_set_black_lower at .999
also causes the wedge problem, but closer to the dark side.

Further remark: the old ordered dither now seems useless because of its
autocorrelation. Depending on density in the grey wedge, C, M or Y hads
the greates tendency to disappear under K, leading to a rainbow-effect
grey wedge.

The 199 size matrix does fine though, but could even more black than
with the settings used above. But prints look so crisp now!

Now for the changes as relevant to black generation. The full patched
version will be in CVS under print/Matgen in a moment:

I reinstated the old kdarkness generation:

*** 1545,1556 ****
  	   * In between we scale.  We actually choose, for each point,
  	   * whether we're going to print black or color.
  	   */
! #if 0
  	  tk = (((oc * d->c_darkness) + (om * d->m_darkness) +
  		 (oy * d->y_darkness)) >> 6);
! #else
! 	  tk = k;
! #endif
  	  kdarkness = tk;
  	  if (kdarkness < d->k_upper) /* Possibility of printing color */
  	    {
--- 1556,1565 ----
  	   * In between we scale.  We actually choose, for each point,
  	   * whether we're going to print black or color.
  	   */
! 
  	  tk = (((oc * d->c_darkness) + (om * d->m_darkness) +
  		 (oy * d->y_darkness)) >> 6);
! 
  	  kdarkness = tk;
  	  if (kdarkness < d->k_upper) /* Possibility of printing color */
  	    {
***************

Instead of (ok - lb) squared I use this as direct black value, so we
start producing appreciable amounts of black early on.

*** 1574,1588 ****
  		  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
  		}
  	      else		/* All black */
--- 1583,1596 ----
  		  if ((d->dither_type & ~D_ADAPTIVE_BASE) == D_FLOYD)
  		    ditherbit = ((xrand() & 0xffff000) >> 12);
  		  else
! 		    ditherbit = (DITHERPOINT(d, x+150, row+50, 4);
  		  ditherbit = ditherbit * rb / 65536;
  		  if (rb == 0 || (ditherbit < (kdarkness - lb)))
  		    bk = ok;
  		  else
  		    bk = 0;
  #else
! 		  bk = (ok - lb) * 65535 / (ub - lb);
  #endif
  		}
  	      else		/* All black */
***************

And instead of subtracting all the black from the CMY values, I take the
square of the black and subtract that.

*** 1600,1608 ****
      
  	  if (bk > 0)
  	    {
! 	      c -= (d->k_clevel * bk) >> 6;
! 	      m -= (d->k_mlevel * bk) >> 6;
! 	      y -= (d->k_ylevel * bk) >> 6;
  	      if (c < 0)
  		c = 0;
  	      if (m < 0)
--- 1608,1617 ----
      
  	  if (bk > 0)
  	    {
! 	      bk = bk * bk / 65536;
! 	      c -= (d->k_clevel * bk) /128;
! 	      m -= (d->k_mlevel * bk) /128;
! 	      y -= (d->k_ylevel * bk) /128;
  	      if (c < 0)
  		c = 0;
  	      if (m < 0)
***************


Thomas

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

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

Chema Celorio wrote:
> ...
> Ghostscript drivers as well as other printer drivers can only
> talk raster data to PCL printers. And in this scenario, with a

Not quite true - the PCL 6 driver (which is a *vector* driver)
doesn't have this limitation, and FWIW all HP printers that support
PCL 6 also support PostScript.

> printer that is doing 36 ppm, we can't print at 600 dpi's because
> of the bottle neck between the printer and the print server.

Well, it depends on what you are sending and if you have a fast
interface, such as a JetDirect.  A typical page of compressed PCL
data at 600 DPI runs about 100k (text, line art, etc.)  For a typical
PC parallel port, you'll be stuck printing 2-3ppm.  A 10baseT
JetDirect will increase this to 5-6ppm, while the 100baseT JetDirect
will run at full speed (assuming your computer can keep up)

> The only way I see that we can talk to a printer at this
> speed (and quality ), is if we download whatever font we need and
> then send data as vectors (goto's, lines, text).

That's what the PCL 6 driver is good for, and most fast printers
seem to support PCL 6 and/or PostScript.

> On the other hand, it doesn't make sense to develop a PCL driver
> that translates from Postscript to PCL, since it will be very
> hard to have full Postcript support. I am thinking of
> "for loops" and complex definitions of definitions of definitions,
> plus the parsing involved.

Ghostscript

> I make such a big issue out of this, because I can't imagine
> an office with this problem using Linux. I haven't made any
> tests yet to meassure the speed problems this creates, but we
> need to be able to support this scenario at the optimal speed.

1. These printers have network interfaces without the typical
   bottlenecks seen with parallel ports.  Some also support USB,
   which is similar in speed to a 10baseT interface.

2. Sending raw print data prevents administrators from doing
   accurate accounting, quotas, billing, etc.

3. Building drivers into GNOME applications does not help non-
   GNOME applications.

> Even some apps that send raster data to the printer in the
> Windows world, can't be used at medium or high speed;
> ie Adobe Acrobat Reader. My HP LJ 6P stopps between
> each page because of this when using AAR.

Ah, but then you're using a parallel interface.  FWIW, you may
see better results by setting your parallel port to ECP or EPP
mode in the BIOS setup.

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

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

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

sh...@al... wrote:
> ...
> Are you sure about that?  According to the documentation, the
> printer will ignore commands that request the printer to print
> outside of the printable region.
> 
> Page 49 of 6clr_99L1.pdf:
> 
>         If image data upon a non-printable region is designated,
>         this designated data is ignored.
> 
> Maybe older model printers don't do that, though.

Gee, you're *trusting* the documentation?  Be advised that there are
(unintentional) errors in the EPSON documentation, both L1 and L2,
that you need to watch out for.  We always use the guides to compare
against the Windows driver output, and stick to the commands used by
the Windows drivers.

Anyways, it depends on the printer you are using.  Older models would
lockup if you sent bad data or data that went beyond the margins.
Current models will print to the width limit, no matter what margins
you've set.

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

Re: [Gimp-print-devel] Ghostscript driver

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

   Date: Fri, 19 May 2000 10:23:25 +0200
   From: Andy Thaller <th...@ph...>

   I've looked over the ghostscript driver part in order to see how
   the canon driver could be added. The gs driver uses the option
   "Model" being an integer value. How about changing this to string
   and check it against printers->driver (which is unique for any
   printer model as I get it). Of course the escp2_* function calls
   would have to be replaced by the appropriate entries in the
   printer_t struct.  Any objections? This would definitely change the
   driver's behaviour in respect to the "Model" option but would
   extend the driver to the canon and hp models unless I've got
   anything completely wrong.

No objection whatsoever.  In fact, this whole numeric parameter thing
is sticking in my craw.  It should really go through the same process
that the plugin goes through, and only allow values appropriate for
the chosen printer model, too.

[Gimp-print-devel] Ghostscript driver

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

I've looked over the ghostscript driver part in order to see how the canon
driver could be added. The gs driver uses the option "Model" being an integer
value. How about changing this to string and check it against printers->driver
(which is unique for any printer model as I get it). Of course the escp2_*
function calls would have to be replaced by the appropriate entries in the
printer_t struct.
Any objections? This would definitely change the driver's behaviour in respect
to the "Model" option but would extend the driver to the canon and hp models
unless I've got anything completely wrong.

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

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

[Chema C. <ch...@ce...>]

Michael Sweet wrote:
> "Corporate" users want accounting, security, quotas, encryption, etc.

When talking about "Corporate" needs, I find a big problem.
( the "iguana" issue )

It seems to me that is is not being solved in any free printing
Unix api except for gnome-print. ( well, I can only speak for Linux,
since that's all the unix I know )

+++ *** Please correct me if I am wrong,
since I might have overlooked something.*** +++

Here is the scenario :
Office, network, 36 ppm PCL printer conected to a box acting as a
print server.
Joe, the user wants to print a database report or a worksheet.
[ which is a VERY common scenario ]

Ghostscript drivers as well as other printer drivers can only
talk raster data to PCL printers. And in this scenario, with a 
printer that is doing 36 ppm, we can't print at 600 dpi's because
of the bottle neck between the printer and the print server.
The only way I see that we can talk to a printer at this
speed (and quality ), is if we download whatever font we need and
then send data as vectors (goto's, lines, text).

On the other hand, it doesn't make sense to develop a PCL driver
that translates from Postscript to PCL, since it will be very
hard to have full Postcript support. I am thinking of 
"for loops"
and complex definitions of definitions of definitions, plus the parsing
involved.

I make such a big issue out of this, because I can't imagine
an office with this problem using Linux. I haven't made any
tests yet to meassure the speed problems this creates, but we 
need to be able to support this scenario at the optimal speed.

Even some apps that send raster data to the printer in the 
Windows world, can't be used at medium or high speed;
ie Adobe Acrobat Reader. My HP LJ 6P stopps between
each page because of this when using AAR.

> Sending raw print data to the printing system prevents that
> functionality from being realized, making wider acceptance of GNOME,
> Linux, etc. more difficult.
> 

about this, we have a Meta-driver that can talk non-raw data to 
a print server. And the print server can generate the raw data.

Chema

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

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

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

Are you sure about that?  According to the documentation, the printer
will ignore commands that request the printer to print outside of
the printable region.

Page 49 of 6clr_99L1.pdf:

	If image data upon a non-printable region is designated, this
	designated data is ignored.

Maybe older model printers don't do that, though.

Eric