Re: [Gnome-print] Re: RFC: A draft proposal ...

[Damien Diederen <dash linuxbe org>]

Hello !

Chema wrote:
> > I don't quite grasp why a GhostScript/Libart frankeinstein couldn't serve
> > our need (the extension could be described in the XPD, and emulation
> >
> 
> several reasons, from the top of my mind :
> 
> - we don't own/mantain the ghostcript code, we don't have
> the freedom to develop as we do with our own api.

I understand. 

> - ghostcript is not a full api as gnome-print is
> (i.e. gnome_print_dialog_new() , gnome_print_add_copies_to_dailog() )

I was *not* proposing to dump gnome-print, but rather to make it *use*
a PostScript look-alike language for application <-> rasterizer 
communication. I feel like we are reinventing the wheel by designing
a new meta-data language. Moreover, PostScript is a turing-complete
programming language, allowing "unlimited" flexibility and neat tricks
(user-defined functions, or network-transparent procedural shaders -- 
part of the PostScript level 3+ specification, IIRC).

> - we cant inlcude dependencies as we can with gnome-print

OK.

> - we need it to be gtk/gnome specific, which ghostcript is not
> since we are going to do dialogs, spooling etc.
> - print preview
> - gnome-print is allready a cool api on it's own
>  ....

GhostScript would be the rendering engine, while the dialogs, etc. would be
part of the gnome-print library. The two are complementary.

Lauris is on the same track than me, according to one of his mails :

> >       I guess I'd ask you to compare it to an alternative--is there an
> > alternative?
> 
> IMHO much more useful than extending GhostScript would be general-purpose,
> standalone PS command language (forth?) interpreter with pluggable
> extension modules. Then we can translate back and forth between
> gnome-print and PS with relative ease (currently we can do only
> gnome-print -> PS)

That is *exactly* what I had in mind when writing the RFC ! In fact,
I was just proposing to extend GhostScript to avoid code duplication.
If this cannot be done, how much would it "cost" to develop an extensible,
powerful, modular PS-like language interpreter from scratch ? (the ORBit 
experience showed that it can sometimes be a huge benefit to rewrite
already-available-but-not-practical-to-use code).

> >       So other than transparency, which can be simulated, what does
> > Postscript miss?
> 
> Transparency cannot be simulated within the PS, but has to be done
> externally anyway (maybe in DPS it can?)
> 
> Generally I cannot see much point using PS internally in printing
> architecture. PS is GREAT programming language, but only mediocre in its
> graphics capabilities (not transparency, no 3D, sucking font-handling
> etc.). Its main reason to existence is being the Lingua Franca for
> controlling thousands of different printers (via GS, of course) - and it
> should remain there - it makes no point using it everywhere. Java
> or Python or SVG or whatever other language would do exactly well in
> high-level printing architecture. How about printing client sending
> JavaScript to backend?

In fact, I'm also language agnostic, but I think it would be neat if the
chosen language were PS-like. An application that only needs PS commands
could send them directly to the printer, without translation. A PostScript
printer could be described in two XPD files :

* Pure PostScript printer, without "Gnome" extensions : The tray selection,
etc. would be described as commands in the XPD, and the application could 
only use "standard" PS commands, which are sent directly to the printer.

Application -A-> GnomePrint ~P~> Spooling -P-> Daemon -P-> Printer

A: API calls
P: PostScript
~: Network transparency

* Gnome Print System printer : The application could use *any* of the gnome-
print features, and the system would have to provide emulation for the features
not supported in the printer (alpha transparency comes to mind). In the worst
case (many unsupported and exotic features), the whole page would be rasterised
and then sent to the printer (this is the printer driver's problem). 

App. -A-> GnomePrint ~G~> Spooling -G-> Daemon -G-> GnomeScript -R-> Printer

A: API calls
G: GnomeScript PostScript look-alike language, with printer driver extensions.
R: Raster data, or a mix of PostScript and Raster data.

The API calls could as well be gnome_print_ps_moveto(...)-style as 
gnome_print_ps_write("/foo { ... } bind def"). Of course, ..._ps_write()
would only accept pure PostScript language and extensions defined in the XPD
file.

In fact, nothing would prevent us to implement other APIs in that PostScript-
like language (of course, I'd rather not send it to a standard printer) :

gl_begin
1 0 0 0.5 gl_color_4
0 0 0 gl_vertex_3
100 100 100 gl_vertex_3
...

Loading the Mesa module into the GnomeScript interpreter would allow for pretty
printouts of 3D scenes ;). The corresponding gnome-print API could be :

gnome_print_gl_begin(...);
gnome_print_gl_color_4(...);
...

(and, of course : gnome_print_gs_write("gl_begin 1 0 0 ...") ;)

Cu,
Damien.

-- 
* Pétition contre les brevets logiciels : http://lln.udev.org/sign.php3
-- 
Damien Diederen
dash@linuxbe.org
http://users.swing.be/diederen/