Subject: Re: GR_Image is raster specific
From: Justin Bradford (justin@ukans.edu)
Date: Fri Mar 10 2000 - 16:45:15 CST
> Sounds like the first step will be to upgrade our expat module in CVS to the
> latest release. Do you feel comfortable doing that diff-merge (IIRC, we've
> got a few BEOS-specific tweaks), or should we find someone else to take care
> of that?
I won't have time to do it right away, so if someone else wants to do
that, it would be helpful (it looks like Sam is interested already).
> Embedding one kind of XML inside another is exactly what namespaces are for,
> and knowing James, I suspect that the mechanisms he's added to expat are
> quite clean.
Yes, the namespace stuff it pretty straightforward. More or less, tag
names come back as URI:abiword, or URI:svg, etc. It might require an extra
step in parsing the tag names, but it's trivial and you've already have a
function for converting to token ID, so it can be incorporated there.
We can recognize the namespace to figure out what we're looking at (ie.
svg, awml, mathml, etc) and go to the appropriate code. That's not a
problem.
However, how do I tell the appropriate image about the SVG tags I'm
getting? My understanding of the Abiword word internals (which might be
off) is that we append an image "marker" onto the piecetable in the flow
of reading everything else. Data sections get stuck in this table, too.
Then, when creating the format (ie. code in text/fmt) a GraphicRaster is
created, which finds the appropriate data item and reads it in.
Ok, but the svg code destined for the GraphicVector is going to be parsed
by the loader. It'll have a unique namespace on it, but it's still going
to be parsed. I don't have a GR_ImageVector created yet to feed it too. I
have only a Fragment in the piece table at this point.
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.
> Agreed. Being able to handle SVGs as a standalone entity (just like we do
> now for raster images) is a desirable feature.
>
> Do we want to figure out the switching mechanism for other raster image
> formats (JPG, BMP, etc.) first, so we can take advantage of it here?
Well, I don't think we need the switching mechanism for loading abiword
documents. (They'll always contain SVG and PNG, right?).
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).
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.
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?
Justin
This archive was generated by hypermail 2b25 : Fri Mar 10 2000 - 16:45:28 CST