Re: GNOME spreadsheet work in progress

[Federico Mena Quintero <federico nuclecu unam mx>]

>  OK, I'm not sure we discuss the same point; and that may be the
>  reason why I don't understand some of the arguments. But I hear
>  some things and definitely agree. I really agree that the graphical
>  object facility that comes with gnome-canvas is more than
>  useful. But the Pb is that I do not know gnome-canvas and have no
>  sample prog to test it (or to start a test).

OK.  There is example code of using the canvas in
gnome-libs/test-gnome/canvas.c.  The testgnome program has some simple
demos of using the canvas.

>  But if you tell me gnome canvas knows how to write fonts, stretch them,
>  rotate them.. 

Right now it only has very basic font support -- you pass an XLFD to
the text item, and it uses that.  I have to write the code that will
provide a sane font handling API to Gtk, so that you can do something
like

	Font *font = font_load ("helvetica");
	font_scale (font, 50);
	font_make_bold (font);

I will be taking a good look at Tk's font handling code, as it seems
to do this kind of stuff nicely.

As for displaying rotated text, GnomeCanvas cannot do it either -- X
does not support it, and GnomeCanvas only knows about the X drawing
primitives.  I think Raph's extremely cool font rendering code can be
adapted to work quickly on a normal X drawable.

>  If gnome-canvas can draw dot lines, cross lines,  ...

Right now I do not support stippling yet, but it should be a snap to
implement.  For the more complex styles that you want, (i.e. sample
the line at every N units and draw a marker there), a special canvas
item could be written to handle it quickly.  It's not hard to do.

>  if gnome canvs knows who to fill objects, clip regions ...

It does filled objects, but it cannot clip paths.  For this you would
need Raph's GtkCaanvas, which internally handles everything as Bézier
curves and can clip them, merge them, etc.

>  If you think it is really designed to produce (small) PS files
>  (I mean if the code is easy to write)

Producing Postcript output from the GnomeCanvas should be trivial,
just as it is with the Tk canvas.  Producing PS from the GtkCaanvas
may be harder.  Raph already talked to me about his ideas for doing
this; basically it involves doing some magic with path operations so
as to de-compose the alpha blended paths into normal Postscript paths.

>  But my point was a bit different: how may we ensure that the PS
>  result will be the same that what I see onto the screen (fonts,
>  bezier, ...)

Then Raph's GtkCaanvas is definitely what you want :-) It needs work
in the API side, but as I said, I intend to make it use something
similar to the GnomeCanvas API.  Raph has done an *excellent* job on
his antialiased canvas engine.

  Federico