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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
