cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Manipulating SVGs
Date Thu, 15 Jun 2000 00:22:30 GMT
Ross Burton wrote:
> 
> Hi,
> 
> A need has arisen for Cocoon 2 to be able to manipulate and render SVG
> files.  The rendering is easy - I enhanced the SVGSerializer some time ago.
> However, manipulation of SVGs is harder.  Although this message is in the
> context of a SVG document, it could be any DOM-based document.
> 
> The options for manipulating SVGs:
> 
> * Filters
> * XSP taglibs
> 
> Filters:
> 
> I have created an AbstractDOMFilter which wraps the SAX -> DOM -> SAX
> conversion, which I extend to allow me to filter the Document object.  With
> this I can perform any operation I wish it to support - at the moment I have
> support for adding any transformation to the root element (such as
> "rotate(90) scale(2)" which will rotate the image by 90 degrees clockwise
> and double the size).  However, these operations cannot be arbitary - if I
> want to add a new element or replace the text in a certain tag I have to
> cater for these possibilities in the filter.

Yes, that's the downside of programming power: you can do whatever you
want, but you have to do it all by yourself.
 
> XSP:
> 
> With XSP it would be perfectly possible to create dynamic SVG documents, but
> they would have to be created from scratch.  As far as I know it is not
> possible to take a SVG file from the filesystem, perform arbitary
> modifications and stream it along the pipeline.

XSP perform as generators, not filters. Generators are responsible to
_create_ something. Filters are responsible for modifying what is
already there.
 
> What I need is a mixture of the two.  This is where my mad idea came in -
> JavaScript.  If one of the parameters on my SVGFilter was a "execute"
> parameter, the value of which was Javascript code, I could use Mozilla Rhino
> to execute this code.  If I give the JavaScript engine access to a SVG
> document and the Request object, arbitary and complex JavaScript could be
> written to modify the document, create new elements and change text to
> create dynamic images (similar to Flash Generator).

Nah, SVG has built-in dynamic capabilities that these are _client-side_
things. And should be kept so.
 
> Am I correct?

I don't think so. the latest CSIRO SVG viewer has dynamic SVG support
and it's _very_ nice. You can generate a moving wave with a simple sine
function and an SVG DOM call. Impressively powerful if attatched to user
interaction events.

But what events would you use on the server side to trigger that dynamic
behavior? Moreover, filters normally perform _global_ transformations
(rotation, scaling, blurring, etc...)... how can you differ from one
text to the next if all the semantic information was already used by the
precedent pipeline components to transform your stuff into SVG?

> Is there a use case of XSP which I do not know about?

No, Sam is right: what you need is XSLT, with scripting extentions in
case you need more more turing-complete programming power than what XSLT
already provides in its schema.

> Comments on this issue would be appreciated.

Be careful on one thing: SVG is a final language because it contains no
semantic information. Once you transform something into SVG, there is no
way back: all text is text, all arcs are arcs. The only semantic
information is graphically based.

So, when you say 

> arbitary and complex JavaScript could be written to modify the 
> document, create new elements and change text to create dynamic 
> images (similar to Flash Generator).

it doesn't make any sense on the server side, but only on the client
side. (in fact, there is no such thing as server-side Flash, being
dynamic user interaction its very strenght).

So, please, keep well defined the differences between client side
programmability (as in dynamic XHTML or dynamic SVG) and server side
programmability (as in XSLT or XSP).

I might add that I foresee the creation of things like "client side
taglibs" for client-side dynamic languages... something like

 <svg:box>
  <dsvg:cartoon repeat="yes" repaint-background="yes">
   <dsvg:background>
    ... some SVG background for the cartoon ...
   </dsvg:background>
   <dsvg:frame lenght="100ms">
    <svg:line ...>
    .... some SVG ...
   </dsvg:frame>
   <dsvg:frame lenght="150ms" keep-previous="no">
    <svg:text ...>
    .... some other SVG ...
   </dsvg:frame>
  </dsvg:cartoon>
 </svg:box>

which can be translated by a stylesheet into SVG + ecmascript to remove
the need to copy over and over the same programming logic.

This is what should be called a "client side logicsheet", as opposed to
XSP logicsheets that work only on the server side.

As a final remark: such a client side logicsheet could contain both
scripting code as "content" and as "stylesheet". The stylesheet
scripting code is called during XSLT processing, the content scripting
code is called during SVG rendering on the SVG capable client.

I know this is not easy, but if you grasp this, you understood
everything behind it.

NOTE: if the client is not SVG-aware, Cocoon will need to perform
transformations to other media but even if SVG -> Flash is theorically
possible, the complexity of such thing would be incredible, not talking
about SVG -> GIF for cartoon movies as outlined above.

Anyway, the Adobe SVG plugin is very cool and I expect it to become
widly popular very shortly. (unfortunately, their scripting appears to
be somewhat non-compliant with Mozilla's javascript... Sam should chase
them for this :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message