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

[Damien Diederen <dash linuxbe org>]

Hello !

There is a lot of confusion floating around about what I meant in my
"RFC" document. I would like to clarify these thoughts and make myself
understood. Please read _all_ of it before this thread dies in flames.

I do like the work that is done on gnome-print very well, and I certainly
didn't want to criticize it. I was just trying to express my concerns
about some of the extensibility "problems" gnome-print may face in a far
future if its using a 'static' communication model (more on that later).

My point is that the producer of the print data and the rasterizer
should be decoupled (IMHO). While it may not be obvious for 
monolithic applications, Bonobo has already proven it to be necessary,
since the embeddable and the container may not be running on the
same computer.

The link between the component and the application (or another component,
since it could be possible to embed something into some embeddables)
is materialized by the metafile driver when it comes to printing.
This looks to me like we are using a 'language' to transmit
page description from one point to the other.

I would like to further abstract this system. The application could use
that same metafile language to talk to a gnome-aware printing daemon. So the
printing daemon would only be another metafile player, but whose output
is printer-dependant data. While this scheme may not seem worthwhile, it has
an appealing advantage : lazy interpretation of the metafile, which will
be played _at the rythm the printer can handle it_. A collection of
arguments on why this seems better to me can be found in the "RFC".

While this already seems very elegant to me, I was thinking about it
and came to another conclusion : since we are already using a
language to transmit page description (the metafile), why couldn't we
use a complete language, with user-defined functions, etc. ? The
printing daemon would see its status change from a metafile player to 
an *interpreter*. Very interesting, since it would allow us to
transmit not only page descriptions, but also 'painting' functions and
the like to the daemon :

(moveto 0 0)
(lineto 50 100)
(lineto 100 0)
(closepath)
(custom-fill			;; This is the interesting part
  (lambda (x, y)		;; Function that draws a whacky
    (if (xor (even x)		;; pattern inside our path. The function
             (even y))		;; will return a red or a blue pixel
	'(1 0 0)		;; depending on the values of the x and y
	'(0 0 1))))		;; parameters.

In fact, this example uses scheme-like syntax, but this is just syntax,
and only the concept is interesting. This functionnality could as well be
expressed in JavaScript as in a custom-cooked binary format. Of course, 
the problem here is what language to use, and what language do we have
(or do we want to write) and interpreter for ?

I think it is mainly the fact that I was "pushing" PostScript (or rather
forth) for this job that made me misunderstood. I did so because
I rather like the "simplicity" of a PostScript parser, and was hoping for
GhostScript to be up to the task. I had a look at its source code, 
and felt disgusted since it looked like a huge pile of rubbish to me. The
fact that it is actually used in many current projects (DPS/X and
GnuStep come to mind), and that Aladdin is supposed to make money from
it led me to think I was wrong. 

I also wrote a couple of comments below, interspersed with Miguel's
response. Be sure not to miss them ;)

On Wed, Apr 19, 2000 at 01:18:26PM -0400, Miguel de Icaza wrote:
> 
> > I was *not* proposing to dump gnome-print, but rather to make it *use*
> > a PostScript look-alike language for application <-> rasterizer 
> > communication. 
> 
> If you had looked at gnome-print before posting, you would have
> noticed:
> 	1. That is it not a new language
> 	2. That it is a C api that has the *SAME* imaging model as
> 	   Postscript.
> 	3. That the very first driver ever wrote was Postscript.

I had a look at it, and I am in fact very happy with it. I think you 
skipped over the word 'use' in my first sentence. I know that gnome-print
is not a language but a C API.

> > 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 add the features that we need to gnome-print to handle that, and we
> would be able to render them into any Poscript printer, not only the
> Postscript 3+ printers.  
> 
> So, we have a better solution in the end.

I'm also OK with that, and I know we will have the best solution ;). 
my point here was about the 'staticity' (does that word even exist ?)
of the metafiles.

> > 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.
> 
> Please, go read the Ghostscript source code, and tell me "I want to
> work on top of this framework, because it is good".
> I will be waiting for you to come back to tell me that.

As I explained earlier, I read fragments of the GhostScript code and
felt highly disgusted. I was just hoping that they were people that
were familiar with the framework, and that could guide us thru that 
jungle. 

> > If this cannot be done, how much would it "cost" to develop an extensible,
> > powerful, modular PS-like language interpreter from scratch ? 
> Why do I want to write a modular language like PS?  I dont care about
> writing another language for such a little gain.   An application

You are already developing an (albeit simplistic) metafile language. But
it could evolve and grow out of control as the list of features pile
up in gnome-print.

> developer could care *less* about this.

This is none of an application developer's business, except for the people
that need procedural shaders for their most advanced features. As Lauris
pointed out, it is necessary if we do not want to force these applications
to do kludges when they need to print gradients, etc. . The job of the
metafile language would be to serialise application requests, as it is now.
But it would be neat if we could serialize *any* application request, 
and to do this cleanly we are in need for a real language.

> What is wrong with the gnome-print approach?  

Nothing, it is absolutely *perfect*. The application programmer shouldn't
see any change in the published APIs even if my proposal (or an
alternative) were implemented.

> I think your proposal is not realistic.  I will continue working on
> gnome-print, and wait for you to invent a new language.

The example I wrote earlier enlightened me (fear it !). Perhaps it would
be interesting to use scheme (Guile) as a page description language. I
would like to know if the possibility to use an sandboxed guile interpreter
is realistic. The syntax is not too complex, and it would be an interesting
compromise between file size, speed and functionnality. These could be
further improved if gnome-print functions were producing byte-compiled
code.

> Miguel.

I hope this made my point clear, and shows that I don't jump on the
bandwagon without having done my homework. I am ready to devote more time,
ideas, and even code to this project if the Gnome community finds it
worthwhile. And I would also like to be taught while this is not a realistic 
proposal, if it isn't (just to shut me down ;).

Cu,
Damien.

P.S.: Sorry for the bad English, but it is not my native language.

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