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