Re: Canvas shortcomings

[Gustavo João Alves Marques Carneiro <ee96090 fe up pt>]

On 15 Jun 2001, Havoc Pennington wrote:

> 
> Gustavo João Alves Marques Carneiro <ee96090 fe up pt> writes:
> > 
> >   That's why I'm not using GnomeCanvas in my humble application, and
> > making my own canvas instead. There should be an abstraction layer, as
> > there is in Dia, so that CanvasItems' rendering methods should always use
> > the same API, receiving a graphic context object as argument that can be
> > used to either render in aa mode or non-aa mode or printing, without the
> > object even noticing the difference.
> > 
> 
> We're eager to have such a layer included in GTK even, but it's a lot
> of work.

  Hmm. In GTK? You mean we could *print* widgets to postscript? That would
be very interesting.. :)
  Anyway, I have made a small library called nxplot. There is a base class
GObject, Nxplot, that has virtual methods (the rendering API). Its API is
modeled after libplot.
  Derived from Nxplot is NxplotLibplot that is a libplot (from GNU
plotting utils) based implementation that can render either to a
GtkDrawingArea or to a file with any of the libplot's supported types
(too many to remember).
  Also I have NxplotArtft, that is a libart_lgpl and freetype2 based
renderer, that renderes to a pixel buffer and draws into a GtkDrawingArea
with GdkRgb.
  A Gdk based renderer should be easy too.
  So, it's not that hard to implement such a thing. And GnomePrint could
easily be extended with a Gdk based renderer, I guess. Then, GnomeCanvas
would use a single API (GnomePrint) and the world would become a better
place. :)
  Anyway I can help, I'm available, if given plenty of time (I'm a slow
programmer :)

-- 
Gustavo J. A. M. Carneiro
[http://linuxdeec.fe.up.pt/~ee96090]