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

[Federico Mena Quintero <federico helixcode com>]

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

The chunkiness of the interpretation of the metafile is not an issue.
Raph's original proposal for the printing API included a callback
system for printers that like to print in bands.  

It would ask you "I am ready to print a band 1 centimeter tall, full
page width, starting at 5 centimeters down the page", and then you
would be responsible for sending the objects or paths that actually
intersect that bounding box.

This lets you avoid sending a zillion objects or big objects to the
printing system in one shot; think of a very detailed illustration or
a very big raster image.  Instead of sending all the little objects in
the illustration or the whole image, you would only send the objects
and the part of the image that intersect the bands that the printing
system requests from you.

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

The nice thing about the gnome-print metafile format is that, warts
and all, it still is a declarative format that does not involve
executable code.  This is also the nice thing about PDF; you can write
a PDF viewer without all the machinery for a PostScript interpreter.

Device independence is a myth.  Real PostScript files are either tuned
to a particular printer, in which case some stuff may have been
generated by the application specifically for that printer's
capabilities; or it has a bunch of executable PostScript code that
actually generates that stuff for the printer it will be printed on.

In your example for an exotic fill type, you *will* have to tune it to
your particular printer.  Your fancy red/blue pattern will only look
good on very low-resolution printers; are you sure you didn't want a
checkerboard of a specific size instead?  Think of a 2400 DPI
imagesetter; your nice pattern will be a murky glob of ink when the
plates are printed.

I do not know how PDF handles exotic fills and the like.  Maybe PDFs
just have to be generated with a specific printer or screen in mind.
It is not perfect, but it avoids a lot of complexity and still is a
pretty useful format.

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

The gnome-print metafiles need not be any more complex
functionality-wise than PDF.  I think this is a good tradeoff between
simplicity and power.

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

Procedural shaders *need* to tune their output to particular
printers.  Sorry, that's the way it is.  You'll screw up some inkjets
if they cannot print two dots adjacent to each other.  You'll murk up
imagesetters if you don't do a lot of calculations.  Low-resolution
printouts will suck if you send in extreme amounts of detail.

Gradients are not an issue, either.  PS3 supports gradient patches in
very fancy and sexy ways, and I have talked to Raph about implementing
them in libart.  It is not trivial, but it is a fun problem and will
no doubt be solved by a brave hacker.

If you want a really exotic fill type, you'll have to rasterize it
anyways in a custom way for each printer.  Doing it on the application
side instead of the printer driver side lets you avoid a lot of
interpretation an complexity in the metafiles.

As for rasterizing something and then clipping the result with a path,
well, that's libart's problem.  Someone needs to add the necessary
functionality to avoid generating a mask of the clipping path and then
doing the clipping by hand.  It may just be an issue of writing a
filling callback; look at how the SVP rendering code in libart simply
uses a callback that actually paints the pixels.

  Federico