Re: RFC: A draft proposal for the future of the GNOME printing system.

[Chema Celorio <chema celorio com>]

Here are my comments ...
they are short since I need to get some sleep.

Thank you for taking the time to write this Damien,
and your help is welcomed in gnome-print.
There is also a gnome-print list at helixcode.com.
that might be better suited for this kind of
discusion.

Damien Diederen wrote:
> * Spool size : Current systems use a printing daemon which sends data...
> * Network efficiency : For the same reason outlined before, it is...
> * Load balancing : In an enterprise setup, the printing server will do..
> * Driver installation : In a networked printing setup, it is far easier...

there is a meta-data driver ( please see gnome-print-meta.c ) and it
will
be used to print over the network. We are currently focusing on the
imaging
model, and the drivers we are developing will be able to reside and do
the rendering on a print server.

> * Special printer features : The GNOME framework could provide application..
> * Alpha channel support : Most applications won't need alpha channel....
> * Device colorspaces : PostScript already provides a lot of color...

This I found as reasons to not go thru Postcript when the Output device
is not Native Postcript.

> * Printer feedback : My understanding is that the application *should not*...
> * Sudden system load : In a WPS (Windows Printing System)-type architecture,..

we are focusing on the imaging model at this point. 

> * Application components : If PostScript printing were agreed upon, application..

I dont see why is Postcript an advange over native dirvers regarding
this comment.

> * Print preview : It would be a pity to ditch PostScript as a general...
> * Debugging aid : Developers could carefully examine the PostScript code...

Developers can "carefully examine the postcript code" with the current
gnome-print model. They just need to output to the postcript driver.
Hey, I do it!

If the output is fine when using the  Postcript driver and not ok
when using a native driver, then the problem is with the driver and that
is
not the programers problem.

Adding print previewing capabilities to an app is a 20 line hack with 
gnome-print. This is not only beautifull but also a great developing
tool,
as you do not need to waste a lot of paper to have your app print ok.


> * Daemon communication facilities : A set of functions enabling the..

we have not tackle this yet, focusing on the imaging model.




It is important to note that the gnome-print imaging model is
developed after a postcript commands model.
The printing functions are like :
gnome_print_ps_lineto ( ... )
gnome_print_ps_showpage();

etc..

Derek Simkowiak wrote:
>         I haven't been watching the Gnome print system development, but I
> don't see why using Postscript isn't blatantly obvious, for all the
> reasons mentioned in this RFC.  What else could we even consider?

It will be nice if you could take a look at gnome-print.
"blatantly obvious" is a bold statement when you 
"haven't been watching the Gnome print system development"
You can check gedit ver 0.7.0+ ( gedit.pn.org ) printing
code to see  the output quality, code size and printing
options that can be achieved with gnome-print.

Regards ...
Chema