Subject: Re: GR_Image is raster specific
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 15 2000 - 02:32:48 CST
At 08:04 AM 3/14/00 -0500, Leonard Rosenthol wrote:
> The BEST way to store the SVG would be a DOM tree, since
>you'll want/need to get at different parts of the DOM during display.
>The reason you need the DOM tree is to properly deal with CSS
>attributes that might not actually live inline.
Leonard,
Could you give a more specific example of the data structures you have in
mind here? Is it just a more hierarchical variant of what Jeff's done in
more flattened form in the existing piece table via his strux and attrprops?
Also, I'm presuming that the DOM you have in mind here only applies to the
local scope of an individual SVG image. If not, that sounds like it'd cause
some headaches. We're obviously not doing the usual full-blown CSS stuff in
AbiWord, so whatever object model we come up with for the rest of the
document would need to be translated before it could be made available to
the SVG image.
(From the little time I've spent following DOMs and SVG, it seems like those
object models are heavily optimized for the exotic constraints of living
inside web browsers.)
> However, if you aren't going to reparse the SVG after it's
>been rasterized - then just keep it as a single memory block.
Yep. If all we're doing is immediately rasterizing the SVG, then most of
this discussion is moot. We'd just convert to a PNG as far upstream as
possible (using GR_Graphics calls somehow), and store two memory blocks:
- the raw SVG markup (for roundtrip export), and
- the resulting rasterized PNG.
The other complications arise for situations when we *want* the embedded XML
content to be editable, for example in the MathML case.
Paul
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 02:27:17 CST