Hi Stefan,
Stefan Bund <[EMAIL PROTECTED]> wrote on 09/10/2008 10:13:07 AM:
> [EMAIL PROTECTED] writes:
> > Well the purpose of SVGContext is to support the SVG DOM.
> > So adding such a method kind of breaks that. What I would have
> > suggested was using the BridgeContext to lookup the associated
> > GraphicsNode for the DOM element.
>
> Ah ... how can I do that? If that is possible, even better. Please
> remember, I only started looking at batik a few days ago.
You should have the BridgeContext (either you created it or the
Transcoder holds a reference to it as 'ctx'). Then just use
the method:
'GraphicsNode BridgeContext.getGraphicsNode(Node node)'
> I know. The Problem is, that I need to traverse the SVG DOM Tree to
> find the svg:a nodes and then traverse over to the gfp tree to find
> the outline.
Right so the above should make this easy to do.
>
> > So IIRC one of the _big_ problems with the original is that it
> > didn't deal with transforms correctly. Do you handle transforms in
> > the SVG document with your image-map transcoder?
>
> Yes. That's the reason for my changes.
Thats very good.
> I use SVGContext.getCTM() and as far as I understand, this should give
> me the complete transformation even into the graphics space. I also
> preConcatenate the curTxf transform form the SVGAbstractTranscoder
> even though I excpect that to be the unity transformation just to be
> on the safe side.
This sounds good.
