Re: clip-path and onmouseover (or click, onmouseout, etc.) events!
Thanks a lot! I think that Thomas's patch will fix my problem! The problem is that i don't know how to deal with the sources of batik: I donwloaded these (and the patch) but i don't know how i can apply this patch and re-create the jars of the library (Do i need to use a specific ide?). I already downloaded Eclipse, but when I try to open the batik sources, many unresolved import errors are reported. I searched the batik website for any explanation (as i read in the REDME file) but i found nothing about compiling this sources (and applying pathches). Thanks a lot! 2009/8/21 Helder Magalhães helder.magalh...@gmail.com Hi Mathieu, I created a clip-path element: A filled circle masked (more precisely clip-pathed) by a filled rectangle. On the circle element of the svg document, i put a onmouseover and a onmuseout attributes, wich calls a javascript method which changes the color of my shape. The problem is that, when I try this document in batik, the color of the shape changes even when the cursor is over the non-apparent part of the circle: The cursor is outside the rectangle, but would be on the circle if it wasn't clip-pathed, and the part of the circle inside the rectangle changes its color. I guess the specification isn't clear enough regarding this. See bug 46289 [1], which contains a patch by Thomas to fix it and also links to relevant discussions in the www-svg mailing list. :-) With, firefox, i don't have this problem (the color changes only if my mouse is on the part of the circle inside the rectangle). Unclear or underspecified stuff usually leads to this sort of unexpected incoherences among implementations... :-| So I would like to know if it's a bug of batik? Will it be fixed? I'm not sure if the patch will be integrated. I'd vote for so, but I remember the discussion somehow hit a dead end: there was no clear consensus at the time... :-( Maybe this is addressed in the second edition of the SVG 1.1 specification. :-) Can I try to fix it? I tried to search the Javadoc API for the class responsibles for this interpretation, but i've no idea! If there are some batik developpers on this mailing, can they shox me the incriminated classes As stated, in order to fix it you may locally apply the patch already referred. ;-) As stated within the www-svg debate, another way of working around this (in an inter-operable way?) would be adjusting the pointer-events property [2] to visible. Thanks a lot! Hope this helps, Helder [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=46289 [2] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty - To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
Re: clip-path and onmouseover (or click, onmouseout, etc.) events!
Hi Mathieu, The problem is that i don't know how to deal with the sources of batik: I donwloaded these (and the patch) but i don't know how i can apply this patch and re-create the jars of the library (Do i need to use a specific ide?). Naturally, you'll need a JDK [1] or equivalent for building the sources. To build Batik, one only needs to invoke the build command line utility (build.bat for Windows, build.sh for Linux/Mac). Note that you need to define the JAVA_HOME system variable (pointing out to your JDK directory). You probably want to use the target jars to build the jars (as in build jars or ./build.sh jars) and/or squiggle to help testing the patch in test files, if there are any. I already downloaded Eclipse, but when I try to open the batik sources, many unresolved import errors are reported. I've see reports of users using Eclipse, but I don't know about any formal procedure to setup things. I searched the batik website for any explanation (as i read in the REDME file) but i found nothing about compiling this sources (and applying pathches). Applying patches is way out of Batik's scope, so it's expected that you find no information regarding this. Crawling a bit on the subject will probably lead to multiple on-line guides. If you are on Windows and are fond of GUIs, you may for example use TortoiseMerge [2] to help you on the task (but there are a lot more freely available patch/merge tools). ;-) It's weird that no information is found in the README file, although related information can be found in contrib/rasterizertask/README. I'd suggest that a bit of the build related information was ported to the main README file. :-) Thanks a lot! Hope this helps, Helder [1] http://xmlgraphics.apache.org/batik/install.html#distributions [2] http://tortoisesvn.tigris.org/TortoiseMerge.html#patch - To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
Re: clip-path and onmouseover (or click, onmouseout, etc.) events!
Hi Helder, Mathieu, The problem is that, when I try this document in batik, the color of the shape changes even when the cursor is over the non-apparent part of the circle: The cursor is outside the rectangle, but would be on the circle if it wasn't clip-pathed, and the part of the circle inside the rectangle changes its color. Helder Magalhães helder.magalh...@gmail.com wrote on 08/21/2009 12:14:28 AM: I guess the specification isn't clear enough regarding this. See bug 46289 [1], which contains a patch by Thomas to fix it and also links to relevant discussions in the www-svg mailing list. :-) Please read the svg mailing list to understand the complexity of the issue. So I would like to know if it's a bug of batik? Will it be fixed? I'm not sure if the patch will be integrated. I'd vote for so, I would vote no... but I remember the discussion somehow hit a dead end: there was no clear consensus at the time... :-( Maybe this is addressed in the second edition of the SVG 1.1 specification. :-) The spec needs to be updated and until that happens I'm against changing Batik's behavior only to have to change again when the Spec is updated (causing problems for authors that need functionality around this). As stated, in order to fix it you may locally apply the patch already referred. ;-) You can also use an invisible 'blocker' element in addition to the clip to intercept the unwanted events. As stated within the www-svg debate, another way of working around this (in an inter-operable way?) would be adjusting the pointer-events property [2] to visible. I don't think this will work in Batik and I don't think it would be an interoperable. My above suggestion should work for any implementation.
Re: clip-path and onmouseover (or click, onmouseout, etc.) events!
Hi Mathieu, I created a clip-path element: A filled circle masked (more precisely clip-pathed) by a filled rectangle. On the circle element of the svg document, i put a onmouseover and a onmuseout attributes, wich calls a javascript method which changes the color of my shape. The problem is that, when I try this document in batik, the color of the shape changes even when the cursor is over the non-apparent part of the circle: The cursor is outside the rectangle, but would be on the circle if it wasn't clip-pathed, and the part of the circle inside the rectangle changes its color. I guess the specification isn't clear enough regarding this. See bug 46289 [1], which contains a patch by Thomas to fix it and also links to relevant discussions in the www-svg mailing list. :-) With, firefox, i don't have this problem (the color changes only if my mouse is on the part of the circle inside the rectangle). Unclear or underspecified stuff usually leads to this sort of unexpected incoherences among implementations... :-| So I would like to know if it's a bug of batik? Will it be fixed? I'm not sure if the patch will be integrated. I'd vote for so, but I remember the discussion somehow hit a dead end: there was no clear consensus at the time... :-( Maybe this is addressed in the second edition of the SVG 1.1 specification. :-) Can I try to fix it? I tried to search the Javadoc API for the class responsibles for this interpretation, but i've no idea! If there are some batik developpers on this mailing, can they shox me the incriminated classes As stated, in order to fix it you may locally apply the patch already referred. ;-) As stated within the www-svg debate, another way of working around this (in an inter-operable way?) would be adjusting the pointer-events property [2] to visible. Thanks a lot! Hope this helps, Helder [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=46289 [2] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty - To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
