gimp-print-devel

Re: [Gimp-print-devel] What direction should we be headed?

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

Thorsten Schnier wrote:
> ...
> had lots of APIs where they simply could plug in, linux (and unix in
> general) doesn't have anything like that. Of course there is the
> danger of binary-only releases of drivers; if e.g. Epson had been
> able to produce such a thing, they might not have seen the need to
> release printer documentation. But even if they wanted to produce an
> open-source driver, the only way might have been a ghostscript
> driver.

Well, that's one of the things we're talking with EPSON about in
regards to CUPS; basically, CUPS provides all of the things they
need to develop a Linux/UNIX driver, and allows them the option of
a (free) open-source driver license or a (pay) binary license
which then goes to fund CUPS development...

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

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

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

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

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

Re: [Gimp-print-devel] New dither matrix

[Stephan B. <sc...@st...>]

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.

Regards,

Stephan Buchert

Re: [Gimp-print-devel] What direction should we be headed?

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

   Date: Wed, 17 May 2000 22:59:41 +0100
   From: Thorsten Schnier <tho...@sc...>

   Of course it still needs to be possible to create systems that deal with
   large number of print jobs without user interaction; all this has to
   work over networks, simply piping files through the different stages
   still needs to work. 

There's no particular reason that it can't.  Ideally, the driver
itself would tell the application about the printer capabilities, but
it doesn't have to be that way.

   There's another point. About 8 months ago, I had a phone conversation
   with the Australian head of customer support at Epson. In a request (on
   how to transport the printer to the UK), I had as an aside mentioned I
   was disappointed with the support for Linux. One thing he said was that
   it actually quite difficult for them to write something; where windows
   had lots of APIs where they simply could plug in, linux (and unix in
   general) doesn't have anything like that. 

That's an interesting point.

-- 
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] New dither matrix

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

It looks promising.

One problem, though, is that the same matrix is used for everything.
We really need eight uncorrelated (or perhaps two pairs of
anticorrelated) matrices to do it right for 6-color or variable dot
size printers, though.

For the four colors, we could use two pairs of anti-correlated
matrices: probably one pair for K and Y, the other pair for C and M.
If there are slight correlations, it may not matter too much.

However, for variable dot sizes or 6 colors, we have another problem:
we need to pick which color to use.  That really does need to be
uncorrelated with the decision about whether to print at all,
otherwise there will be blotches or odd transition regions.

   Date: Wed, 17 May 2000 22:06:57 +0200
   From: Thomas Tonino <tt...@bi...>

   Also, Random FS (in the patched version) seems to have some artefacts.
   This time I printed a pattern of colored blocks. Random FS shows two of
   these with aright hand edge that gets slighly darker down the page, and
   there is a block (which is a dirty yellow) where 4 magenta and a cyan
   pixel 'escaped' at the bottom. This may be the 'random' in random FS
   though.

The "random" simply means that a random number is used to perturb the
threshold value, as opposed to a matrix value for "hybrid" FS.

   Finally, FS looks better on photographs because it has a sharpening
   effect that is missing in ordered dithers.

Sharpening?  I would think precisely the opposite.

   I take the conclusion that FS is better for dark tints while ordered
   dither now is better for light tints.

That's the theory behind the adaptive dithers.  Since this matrix is a
lot better we can probably try pushing up the cutover point to reduce
the error diffusion artifacts.

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

[Thorsten S. <tho...@sc...>]

Robert L Krawitz wrote:
> 

Before I start, thank you Robert for driving this project which already
has come a long way!

> Well, it's stuff like this that the Unix printing system doesn't
> handle at all.  PDQ does something like this, although it's open loop
> (the knowledge is encapsulated in the printer's PDQ description, not
> queried from the driver, which means that the description needs to be
> kept up to date).  But again, it's all a bunch of little pieces, and
> there's no integration.

I think I am just restating what you are saying below (and I snipped),
but....

At the moment. if I print from, say, xfig, the processing goes 
xfig -> 
transfig (into postscript) -> 
postscript interpreter (into pixmap) -> 
dithering engine -> 
printer driver -> 
spooler -> 
lpd -> 
printer;
 
with postscript interpreter, dithering engine and printer driver
currently in one program. All the steps essentially connected in a
one-way fashion, in the true unix 'tool' philosophy.

What I wonder how much of this really ought to be two-way. Especially:
(a) should the printer driver have to be able to access information from
the printer itself, and (b) should the dithering engine have access to
information from the application? 

You already mentioned reasons for (a), there are also things like
ink-level, type of ink installed, ...

For (b), I could for example think that the application could provide
hints for the dithering engine (this pixel is a pixmap, use photo mode;
this pixel is part of a character, use lineart mode).

Also, where in the steps above is the place for the GUI that lets the
user chose the print quality, number of copies, what kind of paper to
use, what paper tray.... ? This again might need information from both
ends of the chain.

And where is the place for the GUI that pops up and says "the printer
has been switched off and on. Restart job? Abort job ?" I just had a
phone call two days ago from my wife about the printer spewing pages of
garbage...

Of course it still needs to be possible to create systems that deal with
large number of print jobs without user interaction; all this has to
work over networks, simply piping files through the different stages
still needs to work. 

There's another point. About 8 months ago, I had a phone conversation
with the Australian head of customer support at Epson. In a request (on
how to transport the printer to the UK), I had as an aside mentioned I
was disappointed with the support for Linux. One thing he said was that
it actually quite difficult for them to write something; where windows
had lots of APIs where they simply could plug in, linux (and unix in
general) doesn't have anything like that. Of course there is the danger
of binary-only releases of drivers; if e.g. Epson had been able to
produce such a thing, they might not have seen the need to release
printer documentation. But even if they wanted to produce an open-source
driver, the only way might have been a ghostscript driver.

> No objection there.  In fact, I think that all printing applications
> *should* produce PostScript, and despite my reservations about the
> actual implementation of Ghostscript, it's a perfectly valid thing to
> have for printers that don't speak Postscript natively.
> 

Though a 'ghostscript replacement' that could at least also read jpg and
png could save a lot of overhead, and make for much smaller file sizes.


 > We already have a Gnome representative on this list.  For
> completeness' sake, I will contact KDE also.  But a lot of this stuff
> needs to happen at lower levels than that.
> 

Apart from ghostscript, gnome-print, KDE and CUPS, there are at least
three more projects, all on sourceforge, and with commercial support.

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

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

(with an impressive lineup of people)

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.


Plus a lot of other related projects; search for 'print' on
sourceforge...


thorsten

> --
> Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/
> 
> Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lp...@uu...
> Project lead for The Gimp Print --  http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

-- 
----------------------------------------------------------------------- 
                                                       Thorsten Schnier
                                    
                                             School of Computer Science
                                               University of Birminghan
                                                                       
                                               
T.S...@cs...   
                                                   tho...@sc...

[Gimp-print-devel] New dither matrix

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

I built a new dither matrix program that is fast and gives good results.
It is in print/Matgen, including a 199x199 output matrix. Also in Matgen
(I know it shouldn't be there...) is a patched version of print-dither.c
that #includes the 199 size matrix.

Apologies for the large file, but generating it takes a few hours and
I'd like to save you that time.

Preliminary results: I _like_ the output with selecting ordered dither!
A light grey wedge seems much, much smoother than with random FS and
distribution of dots really is neat. Dark areas are a bit noisier though
than with Random FS, but no trace of this colored splotchyness (that
problem may have been solved by other changes though).

With the posted combination good print results can be obtained. A
white-to-black wedge has some problems in the dark area: the transition
from 'dark green' to 'black' (excuse the description) is not smooth: I
think because of the way the matrix is re-used.

In general, dark colors are a bit less smooth than light colors. But a
color like R211/G170/B74 looks better with ordered dither as the
distribution of cyan dots is much smoother.

Also, Random FS (in the patched version) seems to have some artefacts.
This time I printed a pattern of colored blocks. Random FS shows two of
these with aright hand edge that gets slighly darker down the page, and
there is a block (which is a dirty yellow) where 4 magenta and a cyan
pixel 'escaped' at the bottom. This may be the 'random' in random FS
though.

Finally, FS looks better on photographs because it has a sharpening
effect that is missing in ordered dithers.

I take the conclusion that FS is better for dark tints while ordered
dither now is better for light tints.


Thomas

Re: [Gimp-print-devel] What direction should we be headed?

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

Mike Porter wrote:
> 
> I wonder how much of the basic backend to frontend connection work
> that was done for SANE would be useful for printing?  I don't
> ...

Much of it *is* applicable for printing images, but you'd need to
add network support, support for different file formats, abstract
the hardware interface (for security), and add spooling of jobs.

In the end you would end up reinventing IPP (Internet Printing
Protocol), which is what CUPS implements.

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

Re: [Gimp-print-devel] What direction should we be headed?

[Mike P. <mi...@UD...>]

I wonder how much of the basic backend to frontend connection work
that was done for SANE would be useful for printing?  I don't
necessarily mean the code, but rather general concepts that are
part of SANE.  Particularly the dll loading, and a decent way to
describe a user interface.  Well, I guess it's decent - I'm just
starting to look at it!

Printing would probably need frontend<->backend like SANE has along
with a defined interface for a transport mechanism.  It seems like
SANE drivers directly talk to the hardware, which can make for
messier drivers that need to know how to talk SCSI, USB and perhaps
parrellel port.

Mike

Re: [Gimp-print-devel] What direction should we be headed?

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

Thomas Tonino wrote:
> ...
> Ghostscript - or any other application for that matter - could use
> an output format that basically says 'print this pixmap here and
> print that little bit there' and pipe it to our driver. By using
> smaller pixmaps (or maybe even parts as bitmaps which will be
> rendered in black or some other color) we may keep performance okay
> as we do not send all the 'white' through the interface. I have a
> feeling Ghostscript is doing this internally already.

Check out CUPS - http://www.cups.org

We've done exactly this with our "pstoraster" filter, which is
GhostScript without all of the extra drivers and with a new frontend.

We also provide an "imagetoraster" filter that takes image files,
does bilinear interpolation on them, and spits out a raster image.

These filters are used to produce raster images for non-PS printer
drivers, which can then do any dithering, etc. needed.  The filters
also support limited color management based on sRGB color
transform matrices and a unified gamma/density lookup table, and
at some point in the future will support real ICC profiles.

Currently the entire page image is sent - detecting blank areas is
easy and fast, although we've considered modifying the file format
in the future to support blank suppression in Ghostscript if it
becomes a performance problem (it hasn't so far, even when printing
44" wide at 1440x720 DPI with our Stylus Pro 9000 driver)

> ...
> I think a form of concensus is needed: we all need each other.
> Interfaces would help: we'd have a low level driver interface and
> probably various application interfaces. Then there are 2 network
> interfaces right now.

The CUPS driver interface is pretty straight forward, and the image
RIP and raster function code is all GPL'd in CUPS...

Oh, and you'll find data fields in there that can be used to describe
the needed softweave parameters, etc. for the driver (that's what we
use for our Print Pro drivers)

> ...
> Ghostscript allow folks to change some command line parameters
> through (say) PostScript comments? Should save lots of folks all
> those printer queues for 300 dpi, 600 dpi, color, etc.

Why indeed? :)

It is possible to change the resolution, etc. in the PostScript
code:

    <</HWResolution[720 720]>>setpagedevice

This will set the hardware resolution to 720x720 DPI.  Commands
such as these are provided in PPD files, which the print plug-in
supports already to a certain extent, but unfortunately most
applications do not.

However, let me point out that sending images from GIMP as
PostScript to be interpreted by Ghostscript is a very inefficient
method of printing, and doesn't offer much in terms of quality.
Ghostscript doesn't support interpolation of low-resolution
images, and it very slow when it has to halftone those images.

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

Re: [Gimp-print-devel] What direction should we be headed?

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

   Date: Wed, 17 May 2000 08:50:00 +0200
   From: Thomas Tonino <tt...@bi...>

   Or would this still be to inefficient? I also see an open area with
   printer control etc, page size, quality settings (how does the
   information about printer capabilities go up all the way to the user
   interface? Maybe a stupid system: the driver is always identified via
   full (network) path name and can be queried directly).

Well, it's stuff like this that the Unix printing system doesn't
handle at all.  PDQ does something like this, although it's open loop
(the knowledge is encapsulated in the printer's PDQ description, not
queried from the driver, which means that the description needs to be
kept up to date).  But again, it's all a bunch of little pieces, and
there's no integration.

   > But in the
   > long run, projects such as this simply MUST get absorbed into the
   > infrastructure.  In my opinion, of course.

   And that infrastructure would better be general. A lot of apps can only
   print PostScript: so Ghostscript should be part of that infrastructure.

No objection there.  In fact, I think that all printing applications
*should* produce PostScript, and despite my reservations about the
actual implementation of Ghostscript, it's a perfectly valid thing to
have for printers that don't speak Postscript natively.

   The Gimp plugin would be the first app fully excercising the printer
   control features, something sorely missing from Ghostscript. I think it
   needs some very straightforward thinking. Why, for example, doesn't
   Ghostscript allow folks to change some command line parameters through
   (say) PostScript comments? Should save lots of folks all those printer
   queues for 300 dpi, 600 dpi, color, etc.

And in that regard, I think we're performing a valuable service.  It
would be a darn sight more valuable if we'd really come up with a
general mechanism for exposing printer-specific features back to the
application.  Right now we have a specific set of features that we
expose (paper size, paper type, paper source, and so on), and in some
cases we're rather abusing them.  We shouldn't be.  We should allow
printers to define their own sets of attributes.

When I say "exposing printer-specific features back to the
application", I'm referring to a combination of the Gimp and parts of
the plugin.  I think of the "application" in this case as being
primarily print.c, which is the only piece of code that really has
Gimp-specific interfaces embedded within it (*main_window.c and
*color_window.c aren't pure, but they do basically form a generic
printer dialog box).

The current architecture (where the plugin itself generates native
printer output) isn't the right factorization of the problem.  I think
that the right pieces are there, but due to the nature of how things
are right now they're all glommed together (albeit with a
semi-coherent interface).  The actual generation of the printer output
should be done at the very bottom of the stack.  This would allow for
a clean abort of a print job (there is apparently a proper way of
aborting an Epson print job that allows the printer to reset itself
properly), and for printers with bidirectional protocols (like Epson
remote mode).  The Postscript interpreter should be just above that,
and above that should be the queueing system (which is where Unix is
already strong).  Above that should be the a generic printer layer,
which generates Postscript.  So it looks something like this:


APPLICATION			PRINTING SUBSYSTEM	DRIVER

Application
Parts of printer dialog box	Parts of printer	Parts of
				  dialog box		  printer dialog box
							Printer capabilities
PostScript generation
				Job queue
				Generic print filters
				GhostScript or passthrough
				Generic print filters
				Open physical link to
				  printer
							Generate raw output
							  and send to printer

("Open physical link to printer" refers to opening the file descriptor
that will be used to talk to the printer.  This usually requires some
kind of privilege, and we don't want printer drivers themselves to run
with any privilege.)

Now, obviously I'm not proposing that we architect, design, and
implement this ourselves.  It's a big job, and it needs everyone to
buy in to it.  But this seems schematically the right idea, and I want
to think about what we can do to drive the process.

We already have a Gnome representative on this list.  For
completeness' sake, I will contact KDE also.  But a lot of this stuff
needs to happen at lower levels than that.

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

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

Robert L Krawitz wrote:

> Ghostscript is ugly as sin.  It's precisely the monolithic giant that
> Mike refers to.  It's a maintenance nightmare.  It has to be
> recompiled for every new output device you want to add.  Yes,
> recompiled. 

Ghostscript - or any other application for that matter - could use an
output format that basically says 'print this pixmap here and print that
little bit there' and pipe it to our driver. By using smaller pixmaps
(or maybe even parts as bitmaps which will be rendered in black or some
other color) we may keep performance okay as we do not send all the
'white' through the interface. I have a feeling Ghostscript is doing
this internally already.

The output could be in the form of your favourite pixmap format
interleaved with formatting commands. If this format is kept simple, it
should be easy enough to get new frontends to support this.

New backsends are just a pipe to the new Ghostscript with the blocked
output driver.

Or would this still be to inefficient? I also see an open area with
printer control etc, page size, quality settings (how does the
information about printer capabilities go up all the way to the user
interface? Maybe a stupid system: the driver is always identified via
full (network) path name and can be queried directly).

> We have good drivers.  But in infrastructure, we're weak.

I think a form of concensus is needed: we all need each other.
Interfaces would help: we'd have a low level driver interface and
probably various application interfaces. Then there are 2 network
interfaces right now.

> But in the
> long run, projects such as this simply MUST get absorbed into the
> infrastructure.  In my opinion, of course.

And that infrastructure would better be general. A lot of apps can only
print PostScript: so Ghostscript should be part of that infrastructure.
The Gimp plugin would be the first app fully excercising the printer
control features, something sorely missing from Ghostscript. I think it
needs some very straightforward thinking. Why, for example, doesn't
Ghostscript allow folks to change some command line parameters through
(say) PostScript comments? Should save lots of folks all those printer
queues for 300 dpi, 600 dpi, color, etc.


Thomas

[Gimp-print-devel] Highest quality modes for some Epson printers

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

All of the new Epson printers (except for the infamous 440) now
support the "720 dpi highest quality" and "1440x720 highest quality"
modes.  I fixed the weave code to support 8x weave.  It actually
turned out to be very straightforward.

This essentially eliminates all horizontal banding.  However, there's
still a problem that I haven't tracked down.  There's what appears to
be some kind of misregistration between the two subpasses, which
creates some weird stippling that's visible under a loupe.  Edges also
aren't sharp, and when I inspect vertical edges very closely (at
normal 1440), there appears to be a very slight diagonal bias, along
with very slight vertical banding.  I don't know if that means my
print head is slightly out of alignment or if there's some very subtle
bug still lurking.

The way that the highest quality modes work is by assigning each
printed dot in a row to one of two (or, in 720x720 highest quality,
four) sub-rows, each of which is printed in a separate pass.  This is
done by alternating which dot (not which position) gets assigned to
which sub-row.  If I change the assignment routine to assign all of
the dots to one of the sub-rows or the other, everything works well.

The output as parsed by parse-escp2 looks correct.  With all printing
diverted to one of the two sub-rows, all of the expected rows do get
printed.

I'm still looking at this, but I don't expect a quick resolution...

-- 
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: Tue, 16 May 2000 11:16:27 -0400
   From: Michael Sweet <mi...@ea...>

   Basically we have a choice - turn the print plug-in into a monolithic
   giant that supports hundreds or thousands of printers, rivally the
   size of the main GIMP application, or develop the printer drivers
   so they can be used initially from the print plug-in and then
   from Ghostscript and/or CUPS to support high-quality printing from
   all applications.

   UNIX/Linux will not be successful without printer support.  The
   current support for printers sucks.  I've been doing UNIX printer
   drivers for 7 years now, and the general solution to printing is the
   one that works, not writing drivers for individual applications.

I can't find a single word to disagree with here.

One of the original items I put in when I first wrote a roadmap for
this is the eventual elimination of the print plug-in except as glue
code.  That still stands.  The fact that this plug-in is as
comprehensive as it is points to how weak the printing support is in
UNIX.

The UNIX printing system was originally designed at Berkeley to
support networked line printers at the UCB computer center (and if you
look at the man page for lpr, you can *still*, over 20 years later,
find Berkeleyisms -- not BSD, but actual University of California at
Berkeley).  It did a decent job of that.  When System V came along in
the early 1980's or so ATT did it slightly differently.  The commands
have different names, but essentially do the same thing.

Basically, the UNIX printing system is a transport layer.  It does a
good job of transporting bits over the wire to the printer, and
precious little else.  Most everything that has happened in recent
years -- apsfilter and the like -- tries to simplify configuration of
the transport layer, and little else.

Windows, of course, sucks at transport layers.  It's very common for
large organizations to put their networked printers on Unix boxes
(which excel at transport), and the Windows applications print over
the network to a Unix box running Samba.  Since true winprinters
(printers that really need real time control) are still rare, this
works well.

Ghostscript is ugly as sin.  It's precisely the monolithic giant that
Mike refers to.  It's a maintenance nightmare.  It has to be
recompiled for every new output device you want to add.  Yes,
recompiled.  There are no loadable modules (dll's, so's, whatever you
want to call them).  Everything's in a single global namespace.
Yuck.  Yet despite that, for now it's still the best thing out there,
and that's why I consider the Ghostscript driver to be of more
strategic value than the Gimp plugin itself.  Judging by the mail,
there are probably more people using the Ghostscript driver than the
print plugin itself (except for the 2.0 and 3.0 versions bundled with
the Gimp), despite the fact that installing it is a real pain.  Mike's
dead right -- people need the ability to print from ALL applications,
not just from the Gimp.

So why, you may ask, did I start with the Gimp plugin (with Mike's
plugin, that is!)?  Well, it was simple enough.  It was about the only
thing out there I could find that was possible to understand quickly,
the basic architecture was reasonable, and I had just bought a
photo-quality printer that I wanted to use to print images that were,
of course, edited in the Gimp.  I still had a laser printer for other
stuff.

We have a lot more than we started with (I started from Mike's 2.0,
and this project started when I spun off 3.1 from my last 3.0).  We
support more printers, the quality is higher, and we have the
Ghostscript driver.  I believe that we have the best quality printing
available on low-cost printers on Unix.  I'm not aware of any other
free driver that supports anything more than the Stylus Photo EX or
Stylus Color 740, and the Photo EX output I've seen from any other
source is very poor.  We support the 870 -- a current generation
printer -- quite well.  Not perfectly, but quite well.

I see promising stuff going on, with PDQ, gnome-print, and the like.
I think we have useful knowledge to feed into those projects.  We're
driving printers hard, and we're learning what capabilities they have,
and this can be valuable to help the infrastructure folks develop the
necessary API's required for applications to be able to print to these
printers.  We have good drivers.  But in infrastructure, we're weak.

I think that in the short term our direction is good.  We're providing
a target for the infrastructure people to aim at, in terms of what we
can do from the Gimp.  Improving the drivers, of course, enables Unix
folks to use high quality, low cost printers to good effect, and
strengthens the ability of Unix to work on the desktop.  But in the
long run, projects such as this simply MUST get absorbed into the
infrastructure.  In my opinion, of course.

I'd still like to see more discussion over what direction we should
head in.  This is free software, after all, and just because I'm
currently the project lead doesn't mean that I'm the big boss.  Maybe
we're all in agreement here, and we need to figure out how we're going
to help the infrastructure teams absorb our work.  But I do want to
spark some debate.

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

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

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

Re: [Gimp-print-devel] Epson printing to the edge

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

   Date: Wed, 17 May 2000 01:18:03 +0200
   From: Jean-Jacques de Jong <jj...@fr...>

   I compiled the code into ghostscript 6.23 (latest CVS), and it works
   fine - prints at the correct position on the page. 

Great, thanks!

   If you fancy my source RPM of gs-6.23 with the Epson code patch, you can
   get it at http://www.jjdj.net/ghostscript. (I am uploading the thing by
   modem as I am writing this mail, so give it 15 mn from the time stamp of
   this mail).

Tricky point: you shouldn't distribute this code with a non-GPL'ed
version of Ghostscript.  The Aladdin license isn't compatible.
Distributing it with Ghostscript 5.50 is fine, though

   If you try to rebuild the RPM, a patch from the original package (not my
   epson patch) seems to fail (at least on my system): you must enter
   "Makefile" when it prompts what file to patch. I haven't tried to figure
   out what's wrong, I'm not an RPM guru.

I guess Ghostscript finally renamed "makefile" to "Makefile".

Re: [Gimp-print-devel] Epson printing to the edge

[Jean-Jacques de J. <jj...@fr...>]

Robert L Krawitz a écrit :
> 
> I've fixed up the Epson code to print to the top edge and close
> (~5/16") to the bottom.  Printing to the bottom probably will not work
> in microweave or 360 dpi.
> 
> Could someone using Ghostscript (for whom this really matters) please
> test it?
> 

I compiled the code into ghostscript 6.23 (latest CVS), and it works
fine - prints at the correct position on the page. 

If you fancy my source RPM of gs-6.23 with the Epson code patch, you can
get it at http://www.jjdj.net/ghostscript. (I am uploading the thing by
modem as I am writing this mail, so give it 15 mn from the time stamp of
this mail).

If you try to rebuild the RPM, a patch from the original package (not my
epson patch) seems to fail (at least on my system): you must enter
"Makefile" when it prompts what file to patch. I haven't tried to figure
out what's wrong, I'm not an RPM guru.

JJJ

Re: [Gimp-print-devel] What direction should we be headed?

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

Hrafnkell Eiriksson wrote:
> ...
> Is it possible to use the same dithering algorithm for e.g. all
> inkjet printers or do they have to be tweaked so much for each
> specific printer that it is impossible to share the dithering code?
> ...

It depends.

Dithering algorithms need to be optimized for the device they are
used for.  Typically you are looking at either a "clustered dot"
or a "dispersed dot" dithering algorithm depending on the printer.

Raph Levien recently announced that he will provide GPL software
royalty-free use of some of his patents, including some nifty
looking algorithms for dithering that may allow for a good, general
purpose dithering algorithm that will work on all devices; more
info at:

    http://www.levien.com/patents.html

However, dithering is only one part of a larger problem involving
color separation, management, etc.

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

Re: [Gimp-print-devel] What direction should we be headed?

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

On Tue, May 16, 2000 at 11:16:27AM -0400, Michael Sweet wrote:
> Basically we have a choice - turn the print plug-in into a monolithic
> giant that supports hundreds or thousands of printers, rivally the
> size of the main GIMP application, or develop the printer drivers
> so they can be used initially from the print plug-in and then
> from Ghostscript and/or CUPS to support high-quality printing from
> all applications.

I totally agree. 

Is it possible to use the same dithering algorithm for e.g. all
inkjet printers or do they have to be tweaked so much for each
specific printer that it is impossible to share the dithering code?

What is your experience with that? 

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

Re: [Gimp-print-devel] What direction should we be headed?

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

Hrafnkell Eiriksson wrote:
> ...
> What do you mean by filtering? And by user-space?

Filtering, meaning an application that produces PostScript output
needs to have the output filtered (RIP'd, dithered, etc.) for a
non-PS printer.  Other examples of filtering include printing
specific pages (a range and/or even/odd pages), reversing the
order of pages, etc.

> I guess its not user-space vs. kernel-space as I
> see no point in moving any printing software to the kernel.

"user-space" refers to applications that are run by the user or
as the user.  In the case of PDQ and the GIMP print plug-in, the
filtering (dithering, etc.) is done by the user with the raw print
file being sent to the underlying printing system (LPD, CUPS,
whatever)

What I'm saying is that this processing needs to happen at a
system level - not as part of the kernel (although it does get
involved for the final printing since kernel drivers talk to the
parallel, USB, IRDA, etc. ports) but as part of a standard system
service/server/daemon.

Aside from resolving certain security and accounting issues, this
type of architecture provides equal printing services to all users
and applications, and allows for distributed printing, better
management and utilization of resources, etc.  A side effect of
this is that you just need to configure the printer/driver *once*,
and all applications will then see the printer and use it based
upon the information the printing system layer provides.

[stepping up on soap box]

Basically we have a choice - turn the print plug-in into a monolithic
giant that supports hundreds or thousands of printers, rivally the
size of the main GIMP application, or develop the printer drivers
so they can be used initially from the print plug-in and then
from Ghostscript and/or CUPS to support high-quality printing from
all applications.

UNIX/Linux will not be successful without printer support.  The
current support for printers sucks.  I've been doing UNIX printer
drivers for 7 years now, and the general solution to printing is the
one that works, not writing drivers for individual applications.

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

Re: [Gimp-print-devel] What direction should we be headed?

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

Hi

On Tue, May 16, 2000 at 09:36:12AM -0400, Michael Sweet wrote:
>     2. Filtering, printer drivers, color management, etc. should
>        not be done by the user.  Aside from security issues, doing
>        filtering in user-space makes accounting and other "corporate"
>        issues more difficult to address.  We need corporate support

What do you mean by filtering? And by user-space?
I guess its not user-space vs. kernel-space as I
see no point in moving any printing software to the kernel.

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

Re: [Gimp-print-devel] What direction should we be headed?

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

[And here I finally got subscribed, was about to post a long well-
worded response to this thread, and Netscape crashed...  sigh...]

OK, I'm finally "back" to contribute to the print plug-in...  Here
are my thoughts on the future direction of the plug-in and Linux
printing in general:

    1. GIMP and all other applications need a high-level printing
       interface; the GNOME and KDE efforts in this area should
       provide it.

    2. Filtering, printer drivers, color management, etc. should
       not be done by the user.  Aside from security issues, doing
       filtering in user-space makes accounting and other "corporate"
       issues more difficult to address.  We need corporate support
       for Linux to become a mainstream OS (read your computer
       history as to why the IBM PC became so popular despite
       technically superior alternatives)

    3. Legacy applications  (like my crashing Netscape) need to be
       able to access printers through standard commands.

    4. Putting printer drivers in applications is a mistake.  Too
       many application suffer from bloat already, there are all
       sorts of legal (licensing) issues that would be involved,
       and cause problems addressed in #2 and #3.

    5. Good printer drivers are hard to write.  Each printer
       requires a lot of coding and tweeking to make the output
       come out well.

    6. Printer manufacturers are going to provide little or no
       support for our efforts.  My company has enough trouble
       getting information from the various companies for a
       commercial product; NONE of them want to develop or
       support an open-source product right now for their
       entry-level products.

That said, I think future development should go in the direction
of creating a standard set of high-quality printer drivers that
can be used for GIMP, CUPS, Ghostscript, etc.  My personal bias
is of course towards the CUPS-based driver, but I think the
driver internals can be abstracted so that CUPS, GIMP, Ghostscript,
etc. can use the same code so that all applications can take
advantage of the high-quality drivers.

My $0.02.

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

[Gimp-print-devel] Re: Epson 870

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

   Date: Mon, 15 May 2000 22:30:18 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   OK, this is kind of what I have found too, although I didn't find
   that 1440-enhanced whas _that_ bad. It could be a matter of density
   or paper quality as well in that particular case.

Try colors.tif at 1440-enhanced.  There's a very noticeable problem there.

   I think you're right, but a little more light ink would help reduce grain.
   In the version you've tried, I had basically pushed the light-ink button all
   the way down and this is obviously not good. This is how I see the issue:

   1 - there's no issue as long as there's no oversampling.

   2 - With oversampling, any ink value between density/oversampling
   and density

   should work in theory. The former will need to be printed several
   times, the latter only once in a while. The former will give better
   smoothness, the latter better color values. The former will be more
   sensitive to artifacts, like additive errors or soaking the
   paper. Current gimp-print is on the latter side; the safe side,
   whereas my test shot is the former. The issue as I see it, is to
   find a good and stable compromise.

Actually, the current stuff in the repository tries to maintain a
constant density (in terms of number of ink drops/unit area) above a
certain minimum.  It's possible that the calibration isn't right...

[Gimp-print-devel] Re: Epson 870

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

On May 14, 10:41pm, Robert L Krawitz wrote:
> Subject: Re: Epson 870
> First off: the gray scale is much better than mine.
>
> 720 dpi looks pretty good.  1440 looks a bit distorted, and 1440
> enhanced (pseudo-1440x1440) looks positively strange.  I think that
> thaere's some kind of arithmetic overflow going on in darker regions;
> light tones are OK.  It might be the ink budget stuff triggering it, though.
>
> However, in general 1440 and 720 look noticeably different.

OK, this is kind of what I have found too, although I didn't find that
1440-enhanced whas _that_ bad. It could be a matter of density or paper quality
as well in that particular case.

>
> Try downloading http://www.tiac.net/users/rlk/colors.tif.  This is a
> color sweep pattern.
>

Got it.

>
>    2 - I made one major change to dithering. That's how we think about
>    density.  In my understanding, current gimp-print scales everything
>    by density/oversampling. That includes values to print and
>    thresholds.  My approach is to take advantage of oversampling to
>    use (more) lighter inks.  For that purpose, I'm scaling thresholds
>    only by density (not oversampling).  This results in an increase in
>    the usage of light inks as quality (oversampling) increases.
>
> I adopted the approach of scaling everything by density, and ignoring
> the oversampling issue per se (except for scaling density) between
> 3.1.2 and 3.1.3 because the behavior of the 3.1.2 code when the user
> changed density (or resolution) was too unpredictable.  I wanted the
> code to behave identically (as far as ink choice) for any choice of
> density and resolution.
>
> I'm not sure that using more light ink is the way to go.  If anything,
> I think that at high resolution you're often better off using more
> small dots, which means dark ink at some intermediate points, to avoid
> laying down too much ink.
>

I think you're right, but a little more light ink would help reduce grain.
In the version you've tried, I had basically pushed the light-ink button all
the way down and this is obviously not good. This is how I see the issue:
1 - there's no issue as long as there's no oversampling.
2 - With oversampling, any ink value between density/oversampling and density
should work in theory. The former will need to be printed several times, the
latter only once in a while. The former will give better smoothness, the latter
better color values. The former will be more sensitive to artifacts, like
additive errors or soaking the paper. Current gimp-print is on the latter side;
the safe side, whereas my test shot is the former. The issue as I see it, is to
find a good and stable compromise.

>    That's all (or almost), but was not easy with the current
>    dithering. I came across major (and unexpected) color problems. The
>    reason I believe is that for any given density, dithering will use
>    mostly one of 2 inks only (one darker one lighter). Without going
>    into the details, that means that if the settings for only one ink
>    level is not perfect, everything having a color density between the
>    immediately lighter ink and the immediately darker ink will
>    accumulate (and therefore amplify) this error, particularly in flat
>    tones. I think there is a problem with that.
>
> I think you're right.  I think that it should be possible for segments
> to overlap, so that if a particular point lies within multiple
> segments, they're each tried in turn.  I don't know if that would drop
> too much ink, though.
>

As of today, I've been trying to work something from our (mostly common)
conclusions. I'll keep you posted in a few days.

Thanks again for giving it a try and for your helpful comments.


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

[Gimp-print-devel] Re: Epson 870

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

First off: the gray scale is much better than mine.

720 dpi looks pretty good.  1440 looks a bit distorted, and 1440
enhanced (pseudo-1440x1440) looks positively strange.  I think that
thaere's some kind of arithmetic overflow going on in darker regions;
light tones are OK.  It might be the ink budget stuff triggering it, though.

However, in general 1440 and 720 look noticeably different.

Try downloading http://www.tiac.net/users/rlk/colors.tif.  This is a
color sweep pattern.

   Date: Sun, 14 May 2000 22:39:49 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   I would like anyone with an Epson 870 to try what I came up
   with. This is totally experimental at this point and will break
   with any printer other than 6 colors/3 levels printers. In
   addition, my sources are based on ~ last week's version of
   gimp-print. All of the above is very easy to fix though as long as
   dithering doesn't change too much.

I'll be happy to leave this stuff alone for a while...

   2 - I made one major change to dithering. That's how we think about
   density.  In my understanding, current gimp-print scales everything
   by density/oversampling. That includes values to print and
   thresholds.  My approach is to take advantage of oversampling to
   use (more) lighter inks.  For that purpose, I'm scaling thresholds
   only by density (not oversampling).  This results in an increase in
   the usage of light inks as quality (oversampling) increases.

I adopted the approach of scaling everything by density, and ignoring
the oversampling issue per se (except for scaling density) between
3.1.2 and 3.1.3 because the behavior of the 3.1.2 code when the user
changed density (or resolution) was too unpredictable.  I wanted the
code to behave identically (as far as ink choice) for any choice of
density and resolution.

I'm not sure that using more light ink is the way to go.  If anything,
I think that at high resolution you're often better off using more
small dots, which means dark ink at some intermediate points, to avoid
laying down too much ink.

   That's all (or almost), but was not easy with the current
   dithering. I came across major (and unexpected) color problems. The
   reason I believe is that for any given density, dithering will use
   mostly one of 2 inks only (one darker one lighter). Without going
   into the details, that means that if the settings for only one ink
   level is not perfect, everything having a color density between the
   immediately lighter ink and the immediately darker ink will
   accumulate (and therefore amplify) this error, particularly in flat
   tones. I think there is a problem with that.

I think you're right.  I think that it should be possible for segments
to overlap, so that if a particular point lies within multiple
segments, they're each tried in turn.  I don't know if that would drop
too much ink, though.

Raph, are you investigating multi-toned inks for rinkj?

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

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

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

[Gimp-print-devel] Epson 870

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

You haven't heard from me for over a week; I was trying to fix grain/smoothness
for the Epson 870. Here is my first shot.

I have basically implemented my previous suggestions for gimp-print 3.1.3/4.
This has been more difficult than I had expected.

I would like anyone with an Epson 870 to try what I came up with. This is
totally experimental at this point and will break with any printer other than 6
colors/3 levels printers. In addition, my sources are based on ~ last week's
version of gimp-print. All of the above is very easy to fix though as long as
dithering doesn't change too much.

I have tried a lot of different things and this is what seemed to work:

1 - First of all I had to implement my "ink budget" thing for the following to
work. That was the easy part.

2 - I made one major change to dithering. That's how we think about density.
In my understanding, current gimp-print scales everything by
density/oversampling. That includes values to print and thresholds.
My approach is to take advantage of oversampling to use (more) lighter inks.
For that purpose, I'm scaling thresholds only by density (not oversampling).
This results in an increase in the usage of light inks as quality
(oversampling) increases.

3 - the above change involved chnages in the computation of levels.

That's all (or almost), but was not easy with the current dithering. I came
across major (and unexpected) color problems. The reason I believe is that for
any given density, dithering will use mostly one of 2 inks only (one darker one
lighter). Without going into the details, that means that if the settings for
only one ink level is not perfect, everything having a color density between
the immediately lighter ink and the immediately darker ink will accumulate (and
therefore amplify) this error, particularly in flat tones. I think there is a
problem with that. Nevertheless I think I came up with reasonable settings
(which could be improved further). The problem particularly occurs as we use
lighter inks more often because the error amplifies faster then.

Anyway, I would like one or more people to try it (again, only with an epson
750, 870 or another variable size 6 color epson printer). The sources are not
yet very clean, they do not include recent changes (such as tom margin
improvements), but I'm looking for comments on grain/smoothness, particularly
at highest qualities on photo paper by comparison with lower qualities and
current gimp-print.

Instead of posting patches, that would break against current versions, I've put
my sources (print-dither.c, print-escp2.c and print.h are all you need I hope)
at:
"ftp://perse.saclay.cea.fr/pub/incoming/verbavatz/"

Thanks,



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

Re: [Gimp-print-devel] Epson printing to the edge

[Ron v. O. <R.A...@Wb...>]

Robert L Krawitz wrote:
> 
>    Date: Sat, 13 May 2000 11:40:21 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>    Top margin: 0.5 mm !!
>    Bottom margin: 7.0 mm
> 
> I presume this is what you want.  We may be able to get closer to the
> bottom on some of the new printers, although apparently Epson says it
> will lose quality (I think what happens is that if it knows the exact
> page length it can hold the paper by the metal pizza wheel rollers
> near the end and get very close to the bottom of the paper, but the
> printer can't hold the alignment too well there).

It is nice to be able to print close to the edge of the paper, but I
feel it is more important to have some control over the margins.  I
understand this is possible from within gimp but is it possible from
within ghostscript?  

If not, I would prefer a default setting where the printing area is
centered on the paper.

Ron van Ostayen
R.A...@Wb...
Laboratory of Tribology
Department of Mechanical Engineering
University of Technology Delft