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:34:37 GMT
Excellent, this seems like a good idea.  I've got some stuff to work on now and be able to
correctly deal with the CSS to handle layer visibility and colors in the document.
 
Thanks!
 
Michael Bishop

________________________________

From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Sent: Thu 9/21/2006 9:32 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: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