You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by th...@kodak.com on 2008/09/10 13:17:44 UTC
Rudimentary HTML image-map transcoder implementation
Hi Stefan,
Stefan Bund-4 wrote Sep 08, 2008:
> I have implemented a simple and rudimentary HTML image-map transcoder
> for batik. I know, there has already been an implementation by Thomas
> Knodt in 2002 but that seems never to have been added to the batik
> codebase.
Yes, there were some issues with that implementation.
> This is only an initial attempt and I cannot promise to work on it
> much longer, I will try. However I hope that somehow an HTML image-map
> transcoder will make it's way into batik sometime :-)
Well I'll try and take a look at it.
> Here a few words on the patch:
>
> * I added a getOutline member to SVGContext. There was already a
> getBBox call there and getOuline is just a fancy kind of bounding
> box so I thought this to be ok
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.
> * The ImageMapTranscoder itself does not re-build any gvt nodes as the
> old implementation did, it instead uses SVGContext.getOutline
This is better, but I'm not sure why you didn't just lookup the
associated
GraphicsNode and call it's 'getOutline' method. You've broken
encapsulation
already when you need to cast down do a Batik DOM node to get the SVG
Context.
> * I only minimally changed the original code I found as needed to keep
> it simple for me ... it was enough trouble to find out how batik
> works :-)
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? Or do you assume that everything shares
the root SVG's coordinate system?
> I have not attached the code to this mail since I don't know, whether
> this is acceptable on this list. Please let me know whether I should
> post the patch here or open a bug or if you have some other way to
> contribute code.
The best way to contribute a patch would be to create a bug
report (marked as enhancement) and attach the patch there.
Thanks for taking the time to contribute back!
Re: Rudimentary HTML image-map transcoder implementation
Posted by Stefan Bund <as...@gmx.de>.
thomas.deweese@kodak.com writes:
> The problem is that the transcoder tells the bridge context
> that it's a 'static' document. That means that the bridge context
> doesn't need to track this info (so it doesn't). If you set the
> bridge context to either interactive or dynamic then it will work.
> The easiest way to do that is to override createBridgeContext, call
> the base class versions then call 'setDynamicState'.
Perfect. Thanks. I don't know if I would ever have found this
information without your help :-)
> No every DOM node will not have a Graphics Node (like
> anything in a defs or stuff in other namespaces) but all the
> nodes you should be looking at will.
I didn't mean to be absolute on that point ...
I have commited the patch to bugzilla as bug # 45783
https://issues.apache.org/bugzilla/show_bug.cgi?id=45783
I hope, this can be integrated into batik. There will probably be
other changes necessary before this patch is in shape for
inclusion. Please feel free to commet on the code. I can't promise to
work further on it however (time constraints).
Many thanks for your help, thomas.
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rudimentary HTML image-map transcoder implementation
Posted by th...@kodak.com.
Hi Stefan,
news <ne...@ger.gmane.org> wrote on 09/11/2008 11:37:33 AM:
> >> 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)'
> >
> > AAAhh ... I have been searching like mad for a method like that but
> > couldn't find it ... how I came to overlook that, I have no idea.
>
> Sadly it doesn't work, I always get 'null' values back. I don't
> understand how this happens ...
The problem is that the transcoder tells the bridge context
that it's a 'static' document. That means that the bridge context
doesn't need to track this info (so it doesn't). If you set the
bridge context to either interactive or dynamic then it will work.
The easiest way to do that is to override createBridgeContext, call
the base class versions then call 'setDynamicState'.
> I am just using SVGAbstractTranscoder. I call super.transcode in my
> transcoder and then traverse the SVG DOM Tree for A nodes. For those
> nodes I try to get the associated GraphicsNode via
> ctx.getGraphicsNode.
>
> I do not explicitly build any nodes. As far as I understand,
> SVGAbstractTranscoder does build a complete gvt tree so every DOM node
> should have an associated GraphicsNode ?
No every DOM node will not have a Graphics Node (like
anything in a defs or stuff in other namespaces) but all the
nodes you should be looking at will.
Re: Rudimentary HTML image-map transcoder implementation
Posted by Stefan Bund <as...@gmx.de>.
>> 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)'
>
> AAAhh ... I have been searching like mad for a method like that but
> couldn't find it ... how I came to overlook that, I have no idea.
Sadly it doesn't work, I always get 'null' values back. I don't
understand how this happens ...
I am just using SVGAbstractTranscoder. I call super.transcode in my
transcoder and then traverse the SVG DOM Tree for A nodes. For those
nodes I try to get the associated GraphicsNode via
ctx.getGraphicsNode.
I do not explicitly build any nodes. As far as I understand,
SVGAbstractTranscoder does build a complete gvt tree so every DOM node
should have an associated GraphicsNode ?
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rudimentary HTML image-map transcoder implementation
Posted by Stefan Bund <as...@gmx.de>.
> 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)'
AAAhh ... I have been searching like mad for a method like that but
couldn't find it ... how I came to overlook that, I have no idea.
Ok, with that information the thing is even simpler .. perfect. I'll
update my patch accordingly and will then probably post it to the bug
tracker. I'll report back here on this thread with the bug ID.
many thanks,
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rudimentary HTML image-map transcoder implementation
Posted by th...@kodak.com.
Hi Stefan,
Stefan Bund <as...@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.
Re: Rudimentary HTML image-map transcoder implementation
Posted by Stefan Bund <as...@gmx.de>.
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.
> GraphicsNode and call it's 'getOutline' method. You've broken
> encapsulation already when you need to cast down do a Batik DOM node
> to get the SVG Context.
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.
> 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.
> Or do you assume that everything shares the root SVG's coordinate
> system?
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.
The imagemap transform supports the same parameters supported for the
bitmap transforms: height, width, dpi and so on since that's how it is
used: First make an image and then make an image map which needs to
fit the exact dimensions of that image.
> The best way to contribute a patch would be to create a bug report
> (marked as enhancement) and attach the patch there. Thanks for
> taking the time to contribute back!
Thank you for taking the time to understand my ramblings :-)
If you can tell me, how to access the associated graphics node from
the svg node I can adjust my patch accordingly and will then open a
bugreport for this.
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org