cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Schwarz" <saschw...@hotmail.com>
Subject [RT] SVGRenderingTransformer?
Date Fri, 12 Dec 2003 04:15:19 GMT
Hi,

I have a problem for which a general solution might be useful to others
and am looking for feedback on my idea.

As much as I'd like to supply SVG directly to the client; few people have
SVG plugins installed. So, like many of you, I've been using svg2png to
generate images. But SVG also provides for interactivity through
scripting.

To provide some of (scripted) SVG's features I'd like to break up the SVG
image into a number of SVG sub documents, render them each as PNG and then
use html divs to position the subimages at the client in the correct
position relative to the base SVG document origin. (e.g. an office floor
plan where each desk, chair, etc is it's own image extracted from an SVG
document and positioned as they were in the original document).

This idea opens up the ability to use JavaScript for
drag/drop/delete/modify of the presentation layer on JavaScript enabled
browsers. In order to perform the extractions the bounding box would need
to be determined and the transformation to the root coordinate system
calculated. From my cursory investigations the Batik library provides all
of these features(???). This approach would also allow for building image
maps around significant areas of the image using the area's bounding box
dimensions (bbox dimensions can't always be known without rendering;
e.g.complex paths, rendering rectangles around text in arbitrary fonts).

I was thinking of creating an SVGRenderingTransformer that would render
the entire SVG document and then allow extracting subtrees as annotated
standalone SVG documents.

i.e. input pseudo svg doc:
<root>
<svg viewBox="0 0 1512 1512" height="600" width="600">
<defs>....</defs>
<g transform="translate(0, 1320) scale(1,-1)" id="globalTransform">
   <g id="obstacles">
     <svgX:extract>
     <g transform="translate(344,865) rotate(-170,0,0)" id="ac.74">
       <some elements>
     </g>
     </svgX:extract>
     <svgX:extract>
     <g transform="translate(1297,956) rotate(-86,0,0)" id="ac.75">
       <some elements>
     </g>
     </svgX:extract>
   </g>
</svg>
</root>

output pseudo doc (assuming  <svgX:extract> are the extraction elements
and *text* are the values computed by the transformer):
<root>
<svg viewBox="0 0 1512 1512" height="600" width="600">
<defs>....</defs>
<g transform="translate(0, 1320) scale(1,-1)" id="globalTransform">
   <g id="obstacles">
   </g>
</svg>
<svg viewBox="0 0 *minBoundingWidth* *minBoundingHeight*"
width="*minBoundingWidth*" height="*minBoundingHeight*" x="*xWRTRoot*"
y="yWRTRoot" id="ac.74">
       <some elements>
</svg>
<svg viewBox="0 0 *minBoundingWidth* *minBoundingHeight*"
width="*minBoundingWidth*" height="*minBoundingHeight*" x="*xWRTRoot*"
y="yWRTRoot" id="ac.75">
       <some elements>
</svg>
</root>

You could then put XSLT, SourceWriting, and FragmentExtractor Transformers
afterwards in the pipeline to remove, cache, render the individual
elements as PNG/JPG if so desired.

Is a transformer really the right component to implement this functionality?
Of course performance could be an issue for a dynamic data driven
pipelines...
Any Batik power users who know if my speculation on Batik's abilities are
correct?
In addition to extract, other options could include: copy w/o extracting,
wrapping a new root.

Any suggestions or comments would be greatly appreciated!
Thanks,
Steve

_________________________________________________________________
Browse styles for all ages, from the latest looks to cozy weekend wear at 
MSN Shopping.  And check out the beauty products! http://shopping.msn.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message