xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DeWeese Thomas <thomas.dewe...@gmail.com>
Subject Re: updating on JSVGCanvas whithout updating the DOM...
Date Sat, 10 Nov 2012 14:13:13 GMT
Hi Anubhav,

On Nov 5, 2012, at 6:15 AM, Anubhav Tiwari <thecoolguy_18@yahoo.co.in> wrote:

> I have a svg-file which has text tags <text>TRANSFORM</text>
> Through Batik api i read the svg file and set the document in the canvas.
> Now my requirement is to change the TRANSFORM text to TRANSFORM_CHANGED on
> the canvas only. The change should not reflect in the DOM object/document. 
> Firstly, is it possible to make any change on the JSVGCanvas only without
> disturbing the SVG doc object.

	This is software anything is possible...  That said this is an exceedingly bad
idea.  There is essentially no good reason I can think of to go this route rather than
say copying the DOM and using the copied and modified DOM for display.  If you
need some changes in the display DOM reflected in the source DOM it's fairly simple
to write a class that will listen to DOM mutation events and replicate the changes in 
the source DOM.  This also provides you one place to 'filter' your display only changes.

> If yes, i want a place where in Batik we read the text from the GraphicsNode
> and render it on the Canvas.

This is done in the org.apache.batik.gvt.TextNode.  The problem is that the SVGTextElementBridge
that is associated with it assumes that it is the only source of modifications to the TextNode
anytime it decides it needs to change anything it will simply wack your changes out of existence.

> There should be some place at the time of rendering (GVTTreeRenderer) in
> DynamicRenderer.java where the text is again read from the GraphicsNode and
> given to the canvas. 

   This is the TextNode (and it's associated helper classes like StrokingTextPainter).
I'll also say that text rendering is far and away the most complex code in all of Batik,
doing anything with that code makes me nervous and I wrote most of it.  You will 
save yourself a lot of lost sleep by simply leaving it alone.

> Should that be the point i should target to change the text?

	No.  To repeat, trying to muck with the Graphics tree behind the back of the
UpdateManager and Bridges is only going to end in frustration.  The biggest problem
is that your early test code will work just fine, but once you get into more complex situations
you are going to encounter more and more places where you need to try and patch around
the Text Bridge breaking your changes in unexpected ways.  Going the Shadow DOM approach
I mention above is more work up front but will provide a much cleaner architecture for your

    Good luck, and please listen,

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

View raw message