Re: Gdk postscript support

[Owen Taylor <otaylor redhat com>]

Paolo Molaro <lupus@lettere.unipd.it> writes:

> On Mon, Nov 30, 1998 at 06:20:44PM -0500, Owen Taylor wrote:
> > Could you make a "readme" for the patch, explaining what is being
> > changed here and what the patch is meant to do? I really don't like
> > duplicating all the region stuff from X in GDK, especially as it looks
> > like a fairly big performance hit for X... Doesn't Postscript already
> > it's own code for clipping to arbitrary regions? One certainly doesn't
> > want regions scan converted at screen resolution when one could avoid
> > it.
> 
> Ok, I'll write a README for the changes.
> 
> README.
> 
> There are two parts of the patch: the postcript backend and the bits
> that allow custom drawables.
> 
> The latter changes involve:
> 1) GdkDrawableClass: a virtual class for custom drawables: it has
> function pointers for the gdk_draw_* functions and a few others.
> GdkWindowPrivate has a pointer to a GdkDrawableClass struct (engine)

Small quibble, I don't like naming the field name 'engine'. That
name was used for themes because it pointed to something 
we were calling a 'theme engine'. I'm not sure 'Drawable Engine'
makes sense. Something like 'funcs' might be a better name.

> that is used mainly in the gdk_draw_functions.
> gdkwindow.c has very little changes to properly destroy a
> GDK_WINDOW_DRAWABLE window.
> The programmer can register a GdkDrawableClass at any time with
> gdk_drawable_register().
> 2) GdkFont: added the name field with the name of the requested font.

This sounds reasonable. Though I think removing the dependency
of GDK on XLFD names would be a good thing for a future
release.

> 3) GdkGC: it's not possible to retrieve the clip mask/rectangles from
> a X GC, nor it's possible to retreive the dash pattern. 
> Also gdk_gc_get_values returns incorrect values for the foreground
> and background colors (only color->pixel is set, in fact).
> With my changes this information is stored in GdkGCPrivate and can be
> retreived from a drawable backend.
> The problem here is that one can set a region as a clip mask, but
> Region from xlib is an opaque type: it doesn't allow to retreive the
> list of rectangles, so we must have our own version (this can be useful
> for the windows port too, maybe).
> The duplication amounts to less than 10 kb according to size(1).
> The duplication is not in the logic of clipping and such: that is
> the work of the X server or of the postscript interpreter: it only
> allows a programmer to query a GC about anything that can be set in it.
> I can add a flag to GdkGCPrivate (off by default) that controls
> the behavior of GdkGC so it doesn't store the list of rectangles
> of the mask if the programmer doesn't need it.

Hmmmm. A GC created for X can only be used on a particular
depth of X drawable. So it seems a bit strange to me
to expect to be able to use a GC created for X on a postscript
drawable. The way I'd expect things to work, naively, is that
GC's would also be virtualized, and that drawables would
contain a ->create_gc() function.

> The info stored in a GC is important to a GdkDrawableClass to
> draw correctly: this allows us to draw to a postscript file/pipe
> or to a metafile with *very* little effort: this previously
> required a whole X Server and large changes to programs and gdk
> itself and now requires only 12 KB of code :-).
>
> > Also, I don't think the postscript specific stuff belongs in GDK at
> > all right now.
> 
> This is a different issue: if you think that 2000 lines of code to
> allow printing from all gtk+ apps is too much, I can easily put that
> in a separate library along with the metafile stuff, but it would be
> better if it could go in gtk+, IMHO.

There are a couple of issues here:

 - It's not clear to me that the X API is all that well suited
   to producing high quality printed output. I suspect many
   apps may want to use something like the gnome-print library
   (which uses a simplified version of the postscript 
   rendering model) instead.

 - I'm a bit hesitant to rush postscript code into a production
   release of GTK+ when people haven't spent much time 
   using it yet.

> Note that the changes to gdkgc.c, gdkregion.c and gdkdraw.c are essential 
> for this to work.

> > There a also few coding style problems with your patch.
> > (it needs to be:
> > 
> >  if (foo)
> >   {
> >     bar();
> >   }
> 
> Yes. Has anyone the correct options to give to indent?

The default options for (GNU) indent should work pretty
well, I think, because GTK+ sticks to the GNU coding 
standards pretty closely. However, please don't just
run indent over chunks of GTK+ code. In some cases,
especially continuation lines, it will probably remove
some intentional formatting.

Regards,
                                        Owen