Subject: Re: GR_Image is raster specific
From: Justin Bradford (justin@ukans.edu)
Date: Tue Mar 14 2000 - 14:25:10 CST
> >So, should I just write the svg tags back out into a ByteBuf, which gets
> >stored as a data item, which will be found by GraphicVector, which will
> >read it and pass it to GR_ImageVector, which will just use expat to parse
> >the SVG again? It's actually not too inefficient, but I wondering if it is
> >the only solution here.
>
> Do you know what kind of data structure you want to use to store the SVG
> content? Does each drawing primitive correspond to a single XML node with
> attributes? Is the sequencing important? It almost sounds like you may
> want to load them into something a lot like the piece table, which would get
> you I/O more-or-less for free, plus undo/redo for editing.
I'm not sure if you are suggesting that the SVG (or MathML, for that
matter) become a part of the document's piece table, or rather just have
intermediate pieces that get pushed into the the Image later when it's
created.
I don't think the former is a good idea for a couple reasons:
1) This will make vector images very different from raster images.
2) I think we want to encapsulate this data in a discrete location rather
than merge it in with the piece table as a whole. I tihnk this goes for
the MathML/equation editor, too.
As things like SVG and MathML renders (and editors) might one day be
replaced by external components, we want to have it available as a
separate chunk of data.
Similarly, the day will come when a bit of gnumeric (or AbiSheet) XML is
embedded in the AbiWord document. We won't want that to become part of
AbiWord's piece table, too. It should be encapsulated and handed off to a
component that can handle it.
We should probably support undo/redo on (or through?) objects, anyway.
Perhaps they should inherit from a base class with some basic interfaces
(undo, redo, activate [editor?])-- but's veering off into component land.
As the SVG data needs to be fed to the Image/GraphicVector from a couple
different points, it's just easier to handle the parsing in the Image and
probably faster than allocating a bunch of intermediate piece table
fragments.
I think I'll implement it the way I was thinking initially, and then we
can discuss changes from there.
Justin
This archive was generated by hypermail 2b25 : Tue Mar 14 2000 - 14:25:27 CST