Subject: Re: GR_Image is raster specific
From: Paul Rohr (paul@abisource.com)
Date: Fri Mar 10 2000 - 14:56:30 CST
Justin,
IIRC, what you're seeing here is about how far Matt Kimball got when he was
thinking about adding SVG support last summer. As you've noticed he did
most of the required code refactoring, but not quite all of it.
I really like the approach you've proposed here.
At 05:02 PM 3/9/00 -0600, Justin Bradford wrote:
>A (simple) SVG implementation is really quite easy, and completely XP (by
>just drawing with the conventional GR_Graphics classes). Someday, we would
>want to extend GR_Graphics with things like curves, alpha channels,
>gradients, etc, but the SVG implementation could always draw on it, and
>stay XP code.
Yes, yes, yes. That's exactly what I've been hoping for too.
>As for the file format, I was thinking we should use the same design as
>raster images: have a separate data item, but in that data item, we should
>the SVG code.
Hmm. I hadn't thought of moving them out-of-flow like that, but I think I
like it. So long as we know dimensions for that IMAGE box in the layout,
the fact that it's a forward reference shouldn't be a problem.
>I think it would work better if we could pass the SVG XML
>directly to the GR_ImageVector and let it parse the XML itself (so we can
>have SVG input come from multiple entry points (paste, import, and load).
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?
>Of course, this means we have to sneak the SVG code by expat so we can
>save it as a normal data item. Or maybe we can pass control to the
>ImageVector expat handlers somehow? Possibly using the special namespace
>stuff in expat? I'm not sure how we do this yet.
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.
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?
Paul
This archive was generated by hypermail 2b25 : Fri Mar 10 2000 - 14:51:00 CST