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 Mathieu Pedrero <ma...@centraliens-lille.org> on 2009/08/20 20:00:36 UTC

clip-path and onmouseover (or click, onmouseout, etc.) events!

HI Everybody!

I want to ask you a little question, wich concerns the way svg files
are displayed by batik (there isn't any programation issue here):
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.

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).

So I would like to know if it's a bug of batik? Will it be fixed?

Maybe it is a difference of interpretation of the W3C SVG
specifications between Firefox and batik! Is it? (in this case, i
think that firefox interpretation is more logical: if the shape is
masked by a "0-1" mask, only the apparent part must react )

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"

Thanks a lot!

(I work with batik 1.7 and JDK6)

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: clip-path and onmouseover (or click, onmouseout, etc.) events!

Posted by Helder Magalhães <he...@gmail.com>.
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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: clip-path and onmouseover (or click, onmouseout, etc.) events!

Posted by Mathieu Pedrero <ma...@gmail.com>.
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 <he...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>

Re: clip-path and onmouseover (or click, onmouseout, etc.) events!

Posted by th...@kodak.com.
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 <he...@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!

Posted by Helder Magalhães <he...@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org