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

[Damien Diederen <dash linuxbe org>]

Hello !

On Tue, Apr 18, 2000 at 06:50:30AM -0500, Chema Celorio wrote:
[clip] 
> 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.

It is good to hear that you intend to do (at least optional) server-side
rendering. In fact, I was just proposing to use PostScript as a meta-data
language (meta-data *is* a language, after all). This has the advantage
to offer user-defined functions, which are *very* important for 'clever'
printing. Please don't lock ourselves in with a 'static' imaging model.

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

Special printer features -> Described in the XPD file -> 'Proprietary'
GhostScript extensions ('5 gs_hp2000c_set_media_type' anyone ?).

Alpha channel support --> PostScript printer -> Alpha emulation
                      `-> Described in the XPD file -> 'Proprietary' gs
extensions (0.5 1 0 0 gs_setrgbacolor).

Colorspaces -> handled by the PostScript interpreter level 2+

[clip] 
> 
> 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();

I rather think *user-defined functions*, here. With PostScript level 3+,
you can even define shaders/etc. I don't see how you will properly implement
procedural shaders with a 'static' imaging model. 

Of course, the shortcut functions should be named after their PostScript 
counterparts. It's just so *cool* ;)

In fact, I was not proposing to change the gnome-print API, but just to
create a PostScript compatible backend. So you could do :

void draw_star(GnomePrintContext *c, ...)
{
	...
	gnome_print_ps_moveto(c, points[0].x, points[0].y);
	for(i = 1; i < n_points; i++)
		gnome_print_ps_lineto(c, points[i].x, points[i].y);
	gnome_print_ps_stroke();
}

or

gnome_print_ps_write("/drawstar { ... } bind def");
...
gnome_print_ps_write("150 100 drawstar");

Which will result in a smaller metafile if you need to print 3000 stars 
(One could even write a PostScript loop and send it with ..._write()).
It would be technically superior and help DPS applications (no code
duplication). Btw, WYSIWYG applications should use Display PostScript,
IMHO -- and the XFree DPS/X extension should be improved.

[clip]
> code to see  the output quality, code size and printing
> options that can be achieved with gnome-print.

A PostScript-compatible gnome-print would not alter the API, only offer
additional flexibility for those that need it.

> Regards ...
> Chema
> 

Cu,
Damien.

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