xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <Michael.Bis...@je.jfcom.mil>
Subject RE: Visibility on an element?
Date Thu, 21 Sep 2006 13:21:51 GMT
OK, so if I'm interested in doing this the "correct" way, I'm a little confused.  If I register
an "onload" listener before I hand the document to the canvas, then do I have to manually
boot the SVG/CSS DOMs in order to do what I want?  I thought the JSVGCanvas provided this
functionality, but now it seems I have to load it myself, manipulate it, then hand it to the
JSVGCanvas where it is once again created/loaded for me?
 
Or is it that simply when the document is handed to the canvas, the onload listener is fired
(after building the GVT tree) and then I can safely manipulate the CSS?
 
Michael Bishop

________________________________

From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Sent: Thu 9/21/2006 9:18 AM
To: batik-users@xmlgraphics.apache.org
Cc: batik-users@xmlgraphics.apache.org
Subject: RE: Visibility on an element?



Hi Michael,

"Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on
09/21/2006 09:04:54 AM:

> That's good information to know.  I'm still learning about the GVT tree
vs.
> SVG document and how they relate to what's seen and what's loaded.  So
if I
> change my code to wait for the listener I already have (to date I've
only
> waited for the render when loading the application), it should work
because
> the tree builder has already occurred as well?

   This will work although the render may be quite a noticeable bit
after the tree build.

> Or do I explicitly need to wait for the builder?

   No waiting for the builder only helps you
do your work earlier.  BTW probably the "correct"
way to do this would be to register an 'onload'
DOM event handler with the document, before you
give it to the Canvas.  This way you are a bit
isolated from Batik internals (this is W3C standard
DOM) and will get the call back at the "official"
load time handling time (only very slightly after
tree build completes).

   Also if you are going to manipulate the document
in this 'inspection' phase it will look much
better if you do it before the first rendering
(you will see it one way and then it will 'jump'
to the other).

> ________________________________
>
> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> Sent: Thu 9/21/2006 9:01 AM
> To: batik-users@xmlgraphics.apache.org
> Cc: batik-users@xmlgraphics.apache.org
> Subject: RE: Visibility on an element?
>
>
>
> Hi Michael,
>
> "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on
> 09/21/2006 08:53:19 AM:
>
> > OK, I might be a tad redundant, but just to be sure:
> >
> > I have a GVTTreeRendererAdapter already that listens for
> gvtRenderingComplete.
> > This listener for the tree builder is completely different, correct?
>
>    It's a different listener.  However the listeners are well ordered:
>         SVG Document Load
>         GVT Tree Builder
>         SVG Load Event
>
>         GVT Tree Renderer (perhaps more than once)
>         Update Manager    (perhaps more than once)
>
> >
> > Michael Bishop
> >
> > ________________________________
> >
> > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > Sent: Thu 9/21/2006 8:48 AM
> > To: batik-users@xmlgraphics.apache.org
> > Cc: batik-users@xmlgraphics.apache.org
> > Subject: RE: Visibility on an element?
> >
> >
> >
> > Hi Michael,
> >
> > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote
on
> > 09/21/2006 08:36:21 AM:
> >
> > > Yes, but there might be something going on that I need to wait for.
> What
> > I'm
> > > doing is switching documents in my application (previous page/next
> > page).
> > > Does setting a new SVGDocument in a JSVGCanvas do something that I
> need
> > to wait for?
> >
> >    Yes, you need to wait for the GVTTreeBuilder to complete.
> >
> > > jsvgCanvas.setDocument(svgDocument);
> > > // Wait for some listener to tell me CSS cascade is done...
> > >
> > > I figured this was related to the background color as well and it's
> part
> > of
> > > the problem.  When I switch pages, I want to read the background of
> the
> > page I
> > > switch to, so my color control will match.
> > >
> > > Michael Bishop
> > >
> > > ________________________________
> > >
> > > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > > Sent: Thu 9/21/2006 5:47 AM
> > > To: batik-users@xmlgraphics.apache.org
> > > Cc: batik-users@xmlgraphics.apache.org
> > > Subject: RE: Visibility on an element?
> > >
> > >
> > >
> > > Hi Michael,
> > >
> > > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil>
wrote
> on
> > > 09/19/2006 10:22:29 AM:
> > >
> > > > Any ideas on this?
> > >
> > >    For what ever reason the DOM you are working with does not have
> > > the CSS cascade done.  Are you sure that this node is from the
> > > document in the Canvas and that the canvas was built with
> > > dynamic support?  In some cases the Canvas will clone
> > > the given document so that the document it renders uses the
> > > Batik DOMImplementation.
> > >
> > >    BTW, this is just another manifestation of the same problem
> > > you had with the background color...
> > >
> > > > I tried using the CSSUtilities method.  Here's the
> > > > element I tested:
> > > >
> > > > <g style="display: block" xmlns="http://www.w3.org/2000/svg"
> > > > id="SVGWB-1125B997-4DAD-AB9C-13B0-2D57691CF303"
> > > > xmlns:xlink="http://www.w3.org/1999/xlink"
> > > > xmlns:svgx="http://je.jfcom.mil/svgx" svgx:name="default_layer"
> > > > svgx:type="layer" pointer-events="none"/>
> > > >
> > > > And I got a stack trace that goes into the CSSUtilities:
> > > >
> > > > Caused by: java.lang.NullPointerException
> > > >
> > > >         at
> org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown
> > > > Source)
> > >
> > >
> > >
> > > >
> > > >         at
> > > >
mil.jfcom.cie.whiteboard.util.LayerUtil.isVisible(LayerUtil.java:85)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.WBLayerListItem.initJCheckBox(WBLayerListIte
> > > > m.java:119)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.WBLayerListItem.init(WBLayerListItem.java:10
> > > > 3)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.WBLayerListItem.<init>(WBLayerListItem.java:
> > > > 58)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.WBLayerPanel.rebuildLayerList(WBLayerPanel.j
> > > > ava:68)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.managers.GUIManager.rebuildLayerList(GUIMana
> > > > ger.java:210)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.managers.GUIManager.rebuildLayerInfo(GUIMana
> > > > ger.java:202)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.managers.GUIManager.setSvgDocument(GUIManage
> > > > r.java:184)
> > > >
> > > >         at
> > > >
> >
mil.jfcom.cie.whiteboard.ui.managers.WBManager.setDefaultWhiteboard(WBMa
> > > > nager.java:105)
> > > >
> > > >         at mil.jfcom.cie.whiteboard.Main.main(Main.java:85)
> > > >
> > > >         ... 6 more
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > > > Sent: Sunday, September 17, 2006 8:45 AM
> > > > To: batik-users@xmlgraphics.apache.org
> > > > Cc: batik-users@xmlgraphics.apache.org
> > > > Subject: Re: Visibility on an element?
> > > >
> > > > Hi Michael,
> > > >
> > > > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil>
> wrote
> > on
> > > >
> > > > 09/15/2006 01:29:18 PM:
> > > >
> > > > > Is there any way to determine whether or not an SVG is visible?
> I?m
> > > > looking
> > > > > for a global solution.  I?m trying to work with layers:
> > > >
> > > >    I guess I'm not sure what you mean by visibility.  As you hint
> > > > below visibility doesn't mean much for a group (as any child can
> > > > set 'visibility="visible"' and be visible).  Also many things like
> > > > fill='none' stroke='none', or opacity='0' are treated very similar
> > > > to visibility='hidden'.
> > > >
> > > > > <g style=?display:none?> is the way I indicate a layer is not
> > visible.
> > > >
> > > > I?m
> > > > > sure there are other ways to turn it off as well.
> > > >
> > > >    display:none is a bit different as children can not override
> this.
> > > > Additionally a display:none element won't have any 'peer' in the
> > > > Graphics tree.  The easiest thing is to use the CSS DOM to query
> > > > the value of the 'display' property on the element.
> > > >
> > > > > However, for visible layers:
> > > > >
> > > > > <g> and <g style=?display:block?> would work and I?m
sure there
> are
> > > > other ways.
> > > >
> > > >    In SVG there is display:none and display:<anything else> so you
> > > > simply
> > > > need to check if the display properties value is 'none'.  The
first
> > case
> > > > will have it's parent's value for display.
> > > >
> > > > > Is there a way to find this out?  Maybe at a lower-level?  Is
> there
> > a
> > > > point
> > > > > where Batik decides whether or not to draw a particular object?
> > > > Obviously a
> > > > > <g> tag isn?t typically ?drawn? anyway so this setting would
apply
> > to
> > > > its
> > > > > children which may complicate the solution.
> > > >
> > > >         We use 'batik.bridge.CSSUtilities.convertDisplay(Element
e)'
> > to
> > > > determine this.
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > > For additional commands, e-mail:
> > batik-users-help@xmlgraphics.apache.org
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > > For additional commands, e-mail:
> > batik-users-help@xmlgraphics.apache.org
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> > >
> > >
> > >
> > > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> >
> >
> > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
>
> [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

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




Mime
View raw message