You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Steve Schwarz <sa...@hotmail.com> on 2003/12/17 00:52:48 UTC
Comments?? [RT] SVGRenderingTransformer?
Hi
Does anyone have any comments on this idea?
Thanks
Steve
>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
>
_________________________________________________________________
Tired of slow downloads? Compare online deals from your local high-speed
providers now. https://broadband.msn.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Comments?? [RT] SVGRenderingTransformer?
Posted by Geoff Howard <co...@leverageweb.com>.
Steve Schwarz wrote:
> Hi
> Does anyone have any comments on this idea?
> Thanks
> Steve
I thought it seemed like a cool idea with some promise and I was hoping
someone else would build it! :P
Seriously, I've just gotten into svg a little more this last month and
would think it a pretty big task to do much more than basic animation
handling.
Geoff
>> 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
>>
>
> _________________________________________________________________
> Tired of slow downloads? Compare online deals from your local high-speed
> providers now. https://broadband.msn.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org