Re: Gdk postscript support

[Paolo Molaro <lupus lettere unipd it>]

On Tue, Dec 01, 1998 at 12:34:37PM -0500, Owen Taylor wrote:
> > 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.

Ok, changed.

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

Yes. I guess we will continue to name fonts with strings even for
Type1 or TT.

> 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

Well, we are using a GdkGC, not an X GC:-)
I think we should have the freedom to diverge a bit from the X
model when that's cumbersome.
A GdkGC is tied to a particular depth because of the tile pixmap:
we need only to support a gdk_gc_set_rgb_tile(GdkGC*, guchar* rgb_data,...)
and we have a depth-indipendent GC that can easily use gdk_rgb
when rendering to an X drawable.

> GC's would also be virtualized, and that drawables would
> contain a ->create_gc() function.

That will generate a lot of checks for the proper GC all over
gdk_draw: every draw operation will need to check if the
drawable and the gc match each other. 
We have already a virtualized GC: it's GdkGC.

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

That's right: a DTP or vector graphics app will use postcript
directly anyway, but not all gtk+ programmers are going to learn
postscript! They learnt gdk anyway, and the quality of the
generated postcript is good enough for most of us, with a
simple interface and very little changes to existing code.
My local copy of gnome_canvas has a gnome_canvas_render_to_pixmap()
function that I use to print to a postcript drawable (it's the
same as the paint() function, only drawing to the specified pixmap
and not a temporary one).
Note that with my postscript backend you can embed your own
postscript code and that the mapping between X points and
postscript points can be easily changed to, say, 1000:1.

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

That's fine with me if you don't want gdkps in gtk+ right now
(I can keep a separate library for that), but without the changes
to Gdk that won't work and anyway putting it in gtk+ will make
more people use/improve it.

Thanks,
	lupus