Subject: Re: GR_Image is raster specific
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Wed Mar 15 2000 - 12:41:38 CST
At 12:32 AM -0800 3/15/00, Paul Rohr wrote:
>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?
I haven't looked at the piece table structures, so I can't
comment there - however, there are two possible ways to maintain the
SVG information in a structured way (and of course, there is always
non-structured - ie. just keeping the raw stream, which you may want
to do anyway).
The most common way of doing is in a tree (aka hierarchical)
structure where each element is a node on the tree and if it has
sub-elements they are branches. Also, top level items (global CSS
styles, "defs", etc.) go into a document level branch. This mirrors
how scripting languages refer to the elements of the SVG (or any XML)
document.
The other route is to simply keep separate flat lists
(arrays, etc.) of the top level information (a CSS style list, a
"defs" list, etc.) that you can then refer to during the rendering
process.
>Also, I'm presuming that the DOM you have in mind here only applies to the
>local scope of an individual SVG image.
Right.
>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.
It might be interesting to consider how this would happen
moving forward, since it has some important parts to it - such as the
ability of a user to use an Abi stylesheet on text in an SVG document.
>(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.)
Or at least being accessed from scripting languages.
> > 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.
Not entirely! You still need to maintain one of the two
forms of structures DURING the parsing process for use by the
rasterizer. However, once it's been rasterized - you can toss all
the extra stuff and just keep the PNG and the raw SVG.
LDR
--
----------------------------------------------------------------------------
You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol Internet: leonardr@lazerware.com
America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 12:45:55 CST