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 G33K <g9...@fastmail.net> on 2009/10/11 10:07:25 UTC
Force construction of GraphicsNode, even if display = "none"
It seems that SVG elements that have their display property set to
"none" don't get a GraphicsNode when the GVT tree is constructed. This
is fine for static images, but I want to program an editor where users
should be able to manipulate all elements, and to turn them on and off.
Is there a way to force the creation of a GraphicsNode even for elements
where display = "none", and have the GraphicsNode's visibility set to
false instead?
Regards,
Gerrit
--
http://www.fastmail.fm - Does exactly what it says on the tin
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Force construction of GraphicsNode, even if display = "none"
Posted by th...@kodak.com.
Hi Gerrit,
> > I feel I should also mention that I have yet to encounter anyone
> > that has tried to manipulate the GVT tree directly that wouldn't have
> > been better off manipulating the DOM.
"G33K" <g9...@fastmail.net> wrote on 10/14/2009 12:35:20 PM:
> I am not manipulating the GVT tree, just reading it. I implemented these
> standard transformation handles for scaling, skewing and rotating, so I
> need information like getTransform() and getGlobalTransform() and
> getTransformedBounds().
You might want to look at: getTransformToElement, and getScreenCTM,
and getBBox (all on the SVGLocatable interface).
> To interface with the editor, I have to create wrapper objects, which I
> currently fail to create automatically when switching the display
> property on and off. Thus, I wanted to make sure that even invisible
> elements would retain a GraphicsNode all the time.
Good luck!
Re: Force construction of GraphicsNode, even if display = "none"
Posted by G33K <g9...@fastmail.net>.
> Batik absolutely does create GN for elements that only have
> 'visibility:hidden'. I know that because we have tests to ensure
> that pointer/key events get sent to those elements.
You are correct. It was my bad. I had mixed up the method calls and was
doing the check for a GraphicsNode before unsetting display:none and
setting visibility:hidden.
> I feel I should also mention that I have yet to encounter anyone
> that has tried to manipulate the GVT tree directly that wouldn't have
> been better off manipulating the DOM. So you might want to rethink or
> ask about why you need access to the GN's at all. Your stated reason
> doesn't seem to rise to the level needed, you can easily toggle the
> visibility of nodes through the DOM.
I am not manipulating the GVT tree, just reading it. I implemented these
standard transformation handles for scaling, skewing and rotating, so I
need information like getTransform() and getGlobalTransform() and
getTransformedBounds().
To interface with the editor, I have to create wrapper objects, which I
currently fail to create automatically when switching the display
property on and off. Thus, I wanted to make sure that even invisible
elements would retain a GraphicsNode all the time.
Thanks for your help!
Gerrit
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Force construction of GraphicsNode, even if display = "none"
Posted by th...@kodak.com.
Hi Gerrit,
"G33K" <g9...@fastmail.net> wrote on 10/12/2009 04:09:26 AM:
> > It seems that SVG elements that have their display property set to
> > "none" don't get a GraphicsNode when the GVT tree is constructed.
>
> Update: I found an entry in the W3C spec which says that elements with
> display:none "are not present in the rendering tree":
Correct, this is at least partly why GN aren't built for
these elements/subtrees.
> However, this limitation doesn't seem to hold for the visibility
property
> mentioned in the same section of the spec. But in my tests, elements
with
> visibility:hidden (without display:none) still don't seem to get a
> GraphicsNode. Is there a way to force a generation here?
Batik absolutely does create GN for elements that only have
'visibility:hidden'. I know that because we have tests to ensure
that pointer/key events get sent to those elements.
> Or am I missing something important?
It would seem so. Can you post an example of the SVG document
you are trying to work with, along with the code you are using?
I feel I should also mention that I have yet to encounter anyone
that has tried to manipulate the GVT tree directly that wouldn't have
been better off manipulating the DOM. So you might want to rethink or
ask about why you need access to the GN's at all. Your stated reason
doesn't seem to rise to the level needed, you can easily toggle the
visibility of nodes through the DOM.
Re: Force construction of GraphicsNode, even if display = "none"
Posted by G33K <g9...@fastmail.net>.
> It seems that SVG elements that have their display property set to
> "none" don't get a GraphicsNode when the GVT tree is constructed.
Update: I found an entry in the W3C spec which says that elements with
display:none "are not present in the rendering tree":
http://www.w3.org/TR/SVG/painting.html#VisibilityControl
So the implementation is probably correct in not allowing for
GraphicsNodes to be created in such a case. However, this limitation
doesn't seem to hold for the visibility property mentioned in the same
section of the spec. But in my tests, elements with visibility:hidden
(without display:none) still don't seem to get a GraphicsNode. Is there
a way to force a generation here?
Or am I missing something important?
Regards,
Gerrit
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org