Subject: Re: GR_Image is raster specific
From: Paul Rohr (paul@abisource.com)
Date: Tue Mar 14 2000 - 02:10:19 CST
At 04:45 PM 3/10/00 -0600, Justin Bradford wrote:
>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.
It's late. The preceding suggestion might be utter nonsense.
>Well, I don't think we need the switching mechanism for loading abiword
>documents. (They'll always contain SVG and PNG, right?).
Correct.
>We just need switches from other formats to SVG, which we then feed to
>GR_ImageVector, which parses the SVG and builds a little in memory list
>for rendering purposes.
>
>So, in loading from, say, a Word document, I hit an embedded WMF image.
>Then, I feed the WMF to the switching mechanism, and it gives me SVG. I
>then create a data item and feed it that buffer of SVG. Then, I append an
>image onto the piecetable (referencing this new data item). Then,
>everything works like normal. This is basically what I do with raster
>images (except I don't have a switching mechanism for non-PNG formats).
Yep.
>I think this will work. My only (minor) concern is that we have to parse
>SVG twice in Abiword files. I'm hoping for (but haven't found) a way to
>tell expat to skip this section, and return it all as a long string. It's
>probably not a big deal, though. It's a trivial amount of code to add to
>the importer and probably only an extra microsecond or so in load time.
Hmm. The importer controls the code which is feeding code into expat, plus
the callbacks which fire when the bracketing tags get issued. If you really
want the whole chunk, you could probably keep track of offsets and grab the
whole chunk yourself. However, expat would still be parsing all that
content to locate the end tag for you, so it's not much of a savings.
>As for the switching mechanism, in general, I'll get back to that. I just
>like to bounce around between things. I want to finally rewrite the field
>code, too, so we can get moving on it. I'd kill for a free week, but I
>don't think they have Spring Breaks in the Real World, do they?
:-)
You're doing fine. Just keep plugging away. As long as something sticks
each time you bounce, we'll keep getting ahead. (That's actually the
approach I tend to take myself.)
Paul
This archive was generated by hypermail 2b25 : Tue Mar 14 2000 - 02:04:48 CST