Hi Anubhav,
On Nov 5, 2012, at 6:15 AM, Anubhav Tiwari <thecoolguy...@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 so
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 work.
Good luck, and please listen,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
