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 Robert Casties <ca...@mpiwg-berlin.mpg.de> on 2003/12/01 21:57:39 UTC
HTML image map transcoder: great but some problems
First of all, thanks to the Batik people and Torsten Knodt for Batik in
general and the experimental image map transcoder in special! I had
already been wracking my mind about how to get HTML image maps out of
Batik when I found Torstens patch in his mail from 2 September 2002.
(http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03068.html)
It works quite nicely, only it seems not to track transformations.
From this SVG file
(http://pythia.mpiwg-berlin.mpg.de/toolserver/digilib-tools/test/collosseo.svg)
I only get areas with coordinates 1 and 0 exclusively. These are rounded
int values from the coordinates in the SVG without the scale transformation.
Batik renders the same nicely into a PNG
(http://nausikaa2.rz-berlin.mpg.de:18080/digitallibrary/servlet/Raster?fn=/experimental/digilib-test/test_2003/svg/collosseo.svg&dw=892&dh=604)
Is there anything special I have to look out for? (I can provide the
code I used.)
Is anybody still working on this or are there better ways to create
image maps from SVG these days?
Thanks
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Thomas DeWeese <Th...@Kodak.com>.
Robert Casties wrote:
> Thomas DeWeese wrote:
>
>>> Should I rather start with the "root" field from
>>> SVGAbstractTranscoder after its transcode() method? It seems to do
>>> all the necessary preparations.
>>
>> The problem is that the 'root' field is the GVT tree. The
>> existing code walks the DOM tree, so unless you want to seriously
>> rework your code you need to stick with that. What you will be
>
> > doing is walking the DOM tree and then 'looking up' the associated
> > node in the GVT tree (under 'root').
>
> I have no problem with reworking the code (it isn't mine anyway :-)
I actually think that walking the DOM tree is better (See below).
> What would be the best way to walk the GVT tree and extract the outlines
> of the shapes? Can I still get to the "href" and "id" attributes? Do I
> have to do my own clipping with the AOI?
Well the container classes implement the collection apis so you
can get an iterator to iterate over the children. You don't really
get href and id from the GVT tree, but you can get the associated
DOM node. One of the nice things you can do with DOM is
getElementsByTagNameNS which can be used to get all the 'a' elements
directly (internally it walks the tree but you don't have to),
this is one of the reasons I would go with iterating over DOM instead
of GVT (of course you would have to watch out for elements in defs etc).
As far as getting outlines you can use getOutline which returns
the concatenated 'shape' for a subtree but this doesn't include
stroke etc. The 'best' thing to use is the
'gvt.ShapeNode.getSensitiveArea()' as this respects stroke bounds and
pointer-events settings. This isn't exposed directly from the
GraphicsNode and doesn't work for subtree's like getOutline does (So
you would have to do work to build it up).
Of course neither takes into account clipping (so implementing
getSensitiveArea may cost you almost nothing extra).
> I will try it and see :-) Is there any in-depth documentation that
> describes the functional relations inside Batik and its rendering process?
Nothing in depth. The best you get is JavaDocs, the primary
classes you will be intersted in are GraphicsNode,
CompositeGraphicsNode, ShapeNode (perhaps ImageNode).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Robert Casties <ca...@mpiwg-berlin.mpg.de>.
Thomas DeWeese wrote:
>> Should I rather start with the "root" field from SVGAbstractTranscoder
>> after its transcode() method? It seems to do all the necessary
>> preparations.
>
>
> The problem is that the 'root' field is the GVT tree. The
> existing code walks the DOM tree, so unless you want to seriously
> rework your code you need to stick with that. What you will be
> doing is walking the DOM tree and then 'looking up' the associated
> node in the GVT tree (under 'root').
I have no problem with reworking the code (it isn't mine anyway :-)
What would be the best way to walk the GVT tree and extract the outlines
of the shapes? Can I still get to the "href" and "id" attributes? Do I
have to do my own clipping with the AOI?
I will try it and see :-) Is there any in-depth documentation that
describes the functional relations inside Batik and its rendering process?
> One issue is if the transcode method 'imports' the given
> Document I'm not sure you can access the imported Doc (you
> could use BridgeContext.getElement(root) to get the root DOM
> Element I suppose)
In my application I'm parsing the file into a SVGDocument anyway (to get
width and height) which I then pass to the transcoder.
Thanks
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Thomas DeWeese <Th...@Kodak.com>.
Robert Casties wrote:
> Thomas DeWeese wrote:
>
>> Essentially you want to do everything in
>> batik.transcoder.SVGAbstractTranscoder.transcode method (you
>> may want to subclass from it) The important thing is that
>> 'isDynamic' must be true otherwise the 'getGraphicsNode' call
>> will fail (you may not want to run onload scripts!)
>
>
> Should I rather start with the "root" field from SVGAbstractTranscoder
> after its transcode() method? It seems to do all the necessary
> preparations.
The problem is that the 'root' field is the GVT tree. The
existing code walks the DOM tree, so unless you want to seriously
rework your code you need to stick with that. What you will be
doing is walking the DOM tree and then 'looking up' the associated
node in the GVT tree (under 'root').
One issue is if the transcode method 'imports' the given
Document I'm not sure you can access the imported Doc (you
could use BridgeContext.getElement(root) to get the root DOM
Element I suppose)
> I shall have another look at it...
Good luck!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Robert Casties <ca...@mpiwg-berlin.mpg.de>.
Thomas DeWeese wrote:
> Essentially you want to do everything in
> batik.transcoder.SVGAbstractTranscoder.transcode method (you
> may want to subclass from it) The important thing is that
> 'isDynamic' must be true otherwise the 'getGraphicsNode' call
> will fail (you may not want to run onload scripts!)
Should I rather start with the "root" field from SVGAbstractTranscoder
after its transcode() method? It seems to do all the necessary preparations.
I shall have another look at it...
Thanks
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Thomas DeWeese <Th...@Kodak.com>.
Robert Casties wrote:
> Thomas DeWeese wrote:
>> Yah, it looks like the basic approach would have significant
>> problems doing this. The biggest issue is the 'piecemeal'
>> building of the tree:
>>
>> class PathGenerator:
>> for (PathIterator path = builder.build (ctx,e).getOutline()[...]
>>
>> If the code built the rendering tree all up front
>> as if it were doing dynamic rendering and then walked
>> the document (see what the other transcoders do when
>> 'onload' events are active):
>
> I'm sorry but I don't understand the Batik code sufficiently (yet ;-)
>
> I compared the code of Torstens Transcoder with the ImageTranscoder
> class that uses an ImageRenderer. Should I rather implement a Renderer?
> The conrete Renderer classes all seem to use Raster and Graphics2D so I
> didn't try to start there.
No!
Essentially you want to do everything in
batik.transcoder.SVGAbstractTranscoder.transcode method (you
may want to subclass from it) The important thing is that
'isDynamic' must be true otherwise the 'getGraphicsNode' call
will fail (you may not want to run onload scripts!)
> Is the current construction OK otherwise?
It isn't what I would do, but it looks like it should basically
work :)
>
> Where would be the best place to hook into to get a tree, preferrably
> with only the visible elements and a transform to the global CS?
>
>> GraphicsNode gn = BridgeContext.getGraphicsNode(e);
>> gn.getOutline();
>>
>> You could then use gn.getGlobalTransform() to transform the
>> outline to the global coordinate system instead of the local
>> coordinate system.
>>
>> Shape gShape =
>> gn.getGlobalTransform().createTransformedShape(gn.getOutline());
>>
>
> Thanks
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Robert Casties <ca...@mpiwg-berlin.mpg.de>.
Thomas DeWeese wrote:
> Robert Casties wrote:
>
>> First of all, thanks to the Batik people and Torsten Knodt for Batik
>> in general and the experimental image map transcoder in special! I had
>> already been wracking my mind about how to get HTML image maps out of
>> Batik when I found Torstens patch in his mail from 2 September 2002.
>> (http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03068.html)
>
>
> I didn't even realize someone had gotten this far (wonder what
> I was doing in September of 2002? :).
You did answer Torsten on his first attempt on 15. August 2002 :-)
> Yah, it looks like the basic approach would have significant
> problems doing this. The biggest issue is the 'piecemeal'
> building of the tree:
>
> class PathGenerator:
> for (PathIterator path = builder.build (ctx,e).getOutline()[...]
>
> If the code built the rendering tree all up front
> as if it were doing dynamic rendering and then walked
> the document (see what the other transcoders do when
> 'onload' events are active):
I'm sorry but I don't understand the Batik code sufficiently (yet ;-)
I compared the code of Torstens Transcoder with the ImageTranscoder
class that uses an ImageRenderer. Should I rather implement a Renderer?
The conrete Renderer classes all seem to use Raster and Graphics2D so I
didn't try to start there.
Is the current construction OK otherwise?
Where would be the best place to hook into to get a tree, preferrably
with only the visible elements and a transform to the global CS?
> GraphicsNode gn = BridgeContext.getGraphicsNode(e);
> gn.getOutline();
>
> You could then use gn.getGlobalTransform() to transform the
> outline to the global coordinate system instead of the local
> coordinate system.
>
> Shape gShape =
> gn.getGlobalTransform().createTransformedShape(gn.getOutline());
>
Thanks
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: HTML image map transcoder: great but some problems
Posted by Thomas DeWeese <Th...@Kodak.com>.
Robert Casties wrote:
> First of all, thanks to the Batik people and Torsten Knodt for Batik in
> general and the experimental image map transcoder in special! I had
> already been wracking my mind about how to get HTML image maps out of
> Batik when I found Torstens patch in his mail from 2 September 2002.
> (http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03068.html)
I didn't even realize someone had gotten this far (wonder what
I was doing in September of 2002? :).
> It works quite nicely, only it seems not to track transformations.
Yah, it looks like the basic approach would have significant
problems doing this. The biggest issue is the 'piecemeal'
building of the tree:
class PathGenerator:
for (PathIterator path = builder.build (ctx,e).getOutline()[...]
If the code built the rendering tree all up front
as if it were doing dynamic rendering and then walked
the document (see what the other transcoders do when
'onload' events are active):
GraphicsNode gn = BridgeContext.getGraphicsNode(e);
gn.getOutline();
You could then use gn.getGlobalTransform() to transform the
outline to the global coordinate system instead of the local
coordinate system.
Shape gShape =
gn.getGlobalTransform().createTransformedShape(gn.getOutline());
> From this SVG file
> (http://pythia.mpiwg-berlin.mpg.de/toolserver/digilib-tools/test/collosseo.svg)
> I only get areas with coordinates 1 and 0 exclusively. These are rounded
> int values from the coordinates in the SVG without the scale
> transformation.
>
> Batik renders the same nicely into a PNG
> (http://nausikaa2.rz-berlin.mpg.de:18080/digitallibrary/servlet/Raster?fn=/experimental/digilib-test/test_2003/svg/collosseo.svg&dw=892&dh=604)
>
>
> Is there anything special I have to look out for? (I can provide the
> code I used.)
>
> Is anybody still working on this or are there better ways to create
> image maps from SVG these days?
>
> Thanks
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org