xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Rudimentary HTML image-map transcoder implementation
Date Thu, 11 Sep 2008 10:34:16 GMT
Hi Stefan,

Stefan Bund <asbund@gmx.de> wrote on 09/10/2008 10:13:07 AM:

> thomas.deweese@kodak.com 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.


Mime
View raw message