Hi,
Le samedi 06 août 2011 à 11:36 +0200, Jean Brefort a écrit :
> There are several possiblities to improve the situation:
> * use librsvg,
> * use lasem (we already optionally use it for maths equations in
> charts),
> * add appropriate code in goffice.
> The second would avoid to depend on librsvg, but I don't know if
> Emmanuel will actively support it in the future, even in the near
> future. Actually we might also consider importing the mathml code in
> goffice.
Why would you want to do that ?
> The third and most demanding solution would be to import the svg paths
> as canvas items. We already have most of what we need in the canvas, and
> we should just write the parser.
I think you highly underestimate the difficulty of SVG rendering, shown
by the fact that all the modern web browsers fail to have a decent
coverage of the SVG 1.1 specification.
> This would also work for wmf files
> (Valek wrote some demo code in goffice in mf-demo.c) and might be
> extended to emf which we do not support at all for now (as far as I
> know). I suppose that OpenDocument graphics (odg) would be a valuable
> target too.
My take would be to convert wmf or odg to svg and use the best svg
library available (librsvg currently) for the rendering.
> About charts, I'm wondering if it would be valuable to rewrite the
> rendering part using the canvas items. It would help for user
> interactions with the graph elements, but might result in some
> performance loss (difficult to know without experimenting).
I'm not sure the conversion of the GogObjects to canvas items would
really help for user interaction. The canvas positioning logic (absolute
move and size of objects) is different to what you want for the graph
objects: relative position and size w.r.t. parent object, modification
of object properties (axis bounds).
Emmanuel.
_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnumeric-list
