xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject RE: Visibility on an element?
Date Thu, 21 Sep 2006 13:32:20 GMT
Hi Michael,

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

> 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?

   No you are just registering the listener (this works if the SVG/CSS 
DOM isn't booted since events are part of "core DOM").

> 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?

   Correct, you are just registering your interest in knowing when
the Canvas has 'loaded' the Document and it is ready for display
(i.e. the SVG/CSS DOM's are fully booted).  So in the event handler
(or handlers) you can then safety query and manipulate the document
using the SVG and CSS DOM interfaces.

> 
> 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
> 
> 
> 
> [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