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 Jake B <ot...@gmail.com> on 2007/08/23 05:20:50 UTC

introducing myself, and a few questions

Hello, my name is Jake Beard, and I am planning to use Batik in a research
project for my university. Because I believe I will be asking a lot of
questions over the next few weeks, I thought it would be good to introduce
myself, and briefly describe my project. The goal of my project is
ultimately to construct an environment for multi-formalism meta-modelling.
Actually, it's even a bit simpler than that. The goal is to take a
meta-modelling environment which we have implemented in Python/Tkinter,
construct a lightweight front-end, and use pieces of the original
environment to power the back-end.

The architecture of the application I would like to build coincides pretty
nicely with the architecture described in this article that I found:
http://www.svgopen.org/2004/papers/MakingSVGaWebServiceinaMessageBasedMVCArchitecture/
The main difference is that, while their frontend is JSVGCanvas, and they
have rolled their own event broker, my front-end will be Firefox, and my
event broker will by an AJAX engine. The AJAX engine pass user interface
events to the server and will poll it for responses. The server, in turn,
will handle user interface events, and will respond by passing strings
containing executable javascript code back to the client.

I'm currently working on a small prototype in order to get familiar with
Batik, and become a bit more knowlegable about the details of the
technologies involved. Basically, I am trying to construct a few basic user
interface widgets (a button, a panel, and a menu) in SVG. I know that the
idea of building standard user interface widgets has been
discussed<http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200310.mbox/%253C3F815582.5AA86F69@fathammer.com%253E>,
and even implemented <http://spark.sourceforge.net/>, but my version will
have a slightly different twist to it, which is that the layout and reactive
behavior of the widgets will be modelled using statecharts (our tool can
generate executable python code). This statecharts will be kept on the
server. The goal of this prototype is to show that widget behavior can be
modelled using statecharts, and to get aquainted with the technologies that
the rest of the project will rely upon.

That's pretty much the gist of what I'm trying to do. I have a few question
to start out. These are fairly open questions, and there may not be a
straightforward way to answer them, or a single correct answer, but I would
nevertheless appreciate any advice anyone could offer:

   1. In the context of the SVG specification, what would be the most
   appropriate way to represent a widget? It would either have to be a
   <g>,<svg> or <symbol>. I think any of these would work, but I'm not sure
   which one would be the truest to the spec.
   2. In the context of extending Batik, what would be the most
   appropriate way to represent a widget? If, for example, in the SVG spec, a
   widget would best be represented as <g> element, then in the context of
   Batik, would the most appropriate way to represent a widget be to create a
   subclass of SVGOMGElement<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGOMGElement.html>?
   Or would there be a better way?
   3. I'd like to leverage the Factory classes in
   org.apache.batik.dom.svg<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/package-frame.html>,
   but I can't figure out how to initialize the attributes of the Element
   objects I've created. They do not have public set methods, and even though
   they implement the Element interface, calling setAttributeNS on them
   does not change their attributes. What is the proper way to set the
   attributes on these objects?
   4. I also cannot seem to append the Element objects produced by the
   factory classes to the SVG document by calling svgRoot.appendChild
   (object). It just doesn't seem to get appended to the DOM tree. Is
   there a special way to attach the objects created by the factory classes (as
   opposed to those created by doc.createElementNS) to the DOM tree?

Thank you very much for reading my very long email. I would appreciate any
guidance anyone can offer.
Thanks.

Jake

Re: introducing myself, and a few questions

Posted by Cameron McCormack <ca...@mcc.id.au>.
Jake B:
> > Also, as a sidenote, I was looking up the javadoc information on the
> > interfaces in org.w3c.dom.svg, and I discovered that the Batik 
> > javadocs link to several classes in org.w3c.dom.svg, but these links
> > appear to be dead.

Thomas DeWeese:
>     I don't know.  The W3C publishes the interfaces as IDL and they
> don't seem to publish java docs.  We might be able to convince
> xml-commons at Apache to generate and publish JavaDocs for the
> external package.

I recently constructed javadocs for the W3C SVG interfaces.  They will
be published some time soon on www.w3.org.  (Just have to prod the right
people again…)

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

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


Re: introducing myself, and a few questions

Posted by th...@kodak.com.
Hi Jake,

> "Jake B" < otakuj462@gmail.com> wrote on 08/22/2007 11:20:50 PM:
> 
> > 3. I'd like to leverage the Factory classes in 
org.apache.batik.dom.svg

> On 8/24/07, thomas.deweese@kodak.com < thomas.deweese@kodak.com> wrote:
> 
>    What Factory classes in batik.dom.svg? 

"Jake B" <ot...@gmail.com> wrote on 08/25/2007 12:31:32 AM:

> These were the factory classes I was talking about: 
> SVGDOMImplementation.AElementFactory 
> SVGDOMImplementation.AltGlyphDefElementFactory 
  [...]

> I'm quite certain now that I was truly misunderstanding the purpose 
> of these classes.

   Yes, those are how we implement 'createElementNS' (extensibly) 
so you are much better off using createElementNS.

> I understand now that the proper thing to do is to
> use the interfaces in org.w3c.dom.svg.

   Yes.

> Right now I'm trying to figure out how bounding boxes work.
[...]
> Unfortunately, rectangle.getBBox() consistently evaluates to null.
[...]
> My question is, what do I need to do to make the getBBox method 
> work?

   You need to boot the SVG DOM:
        http://wiki.apache.org/xmlgraphics-batik/BootSvgAndCssDom

   There is some other good stuff on the Wiki as well.  So you
might want to just skim it so you know what's there.

> If I need to render the document, is it possible to minimally 
> do so in order to simple retrieve the Element's bounding box, or is 
> it necessary to fully render the document in, for example, 
> JSVGCanvas in order to make getBBox work? 

   Booting the CSS/SVG DOM builds the our graphics tree which we
can use for rendering, but no rendering needs to take place.

> Also, as a sidenote, I was looking up the javadoc information on the
> interfaces in org.w3c.dom.svg, and I discovered that the Batik 
> javadocs link to several classes in org.w3c.dom.svg, but these links
> appear to be dead.

    I don't know.  The W3C publishes the interfaces as IDL and they
don't seem to publish java docs.  We might be able to convince
xml-commons at Apache to generate and publish JavaDocs for the
external package.


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


Re: introducing myself, and a few questions

Posted by Jake B <ot...@gmail.com>.
Once again, thank you for replying to my email.

On 8/24/07, thomas.deweese@kodak.com <th...@kodak.com> wrote:
>
> Hi Jake,
>
> "Jake B" <ot...@gmail.com> wrote on 08/22/2007 11:20:50 PM:
>
> > The goal is to take a meta-modelling environment which we
> > have implemented in Python/Tkinter, construct a lightweight front-
> > end, and use pieces of the original environment to power the back-end.
>
>     Well I hope it goes well for you, and hopefully we will be able
> to help you past any rough spots.
>
> > I'm currently working on a small prototype in order to get familiar
> > with Batik, and become a bit more knowlegable about the details of
> > the technologies involved. Basically, I am trying to construct a few
> > basic user interface widgets (a button, a panel, and a menu) in SVG.
> > I know that the idea of building standard user interface widgets has
> been
> > discussed, and even implemented, but my version will have a slightly
> > different twist to it, which is that the layout and reactive
> > behavior of the widgets will be modelled using statecharts (our tool
> > can generate executable python code). This statecharts will be kept
> > on the server. The goal of this prototype is to show that widget
> > behavior can be modelled using statecharts, and to get aquainted
> > with the technologies that the rest of the project will rely upon.
> >
> > That's pretty much the gist of what I'm trying to do. I have a few
> > question to start out. These are fairly open questions, and there
> > may not be a straightforward way to answer them, or a single correct
> > answer, but I would nevertheless appreciate any advice anyone could
> offer:
> > 1. In the context of the SVG specification, what would be the most
> > appropriate way to represent a widget? It would either have to be a
> > <g>,<svg> or <symbol>. I think any of these would work, but I'm not
> > sure which one would be the truest to the spec.
>
>    I would tend to use a 'g'.  The advantage of 'svg' (and also symbol)
> is that it establishes a viewport which first adds a default clip region
> (which could be good or bad) and second gives you some fairly simple
> control of the coordinate system.  That said you actually have more
> control over the coordinate system with 'g' since you can use the
> transform
> but the interface is a bit more complex.
>
>    Symbol is useful if you want to have multiple copies of the
> _exact_ same thing.  As soon as you start creating tweaked versions of
> things to add as 'symbol' elements that you then 'use' you are almost
> always better off just adding the tweaked elements where the use would
> be.
>
> > 2. In the context of extending Batik, what would be the most
> > appropriate way to represent a widget? If, for example, in the SVG
> > spec, a widget would best be represented as <g> element, then in the
> > context of Batik, would the most appropriate way to represent a
> > widget be to create a subclass of SVGOMGElement? Or would there be a
> > better way?
>
>     Don't subclass our DOM Elements unless you want to create custom
> DOM Elements.  I would probably build a separate 'widget tree' with
> your own classes (not directly tied to DOM).  Then I would have
> references to the DOM tree in my widget objects.  The widget objects
> would register callbacks on the DOM objects for events they care about.
>
>     If you need to you could also have a hash table that allowed one
> to go from an arbitrary DOM object to the associated Widget Object
> but in my experience that isn't normally needed (the event listeners
> know what object registered them, so this generally only needed if
> the need to map graphics->widget comes outside of the scope of an
> event).
>
> > 3. I'd like to leverage the Factory classes in org.apache.batik.dom.svg
> > , but I can't figure out how to initialize the attributes of the
> > Element objects I've created. They do not have public set methods,
> > and even though they implement the Element interface, calling
> setAttributeNS
> > on them does not change their attributes. What is the proper way to
> > set the attributes on these objects?
>
>    What Factory classes in batik.dom.svg?  The only two I see are the
> Factory classes for producing Documents.  Documents don't have
> attributes - so perhaps that is your problem?


These were the factory classes I was talking about:
SVGDOMImplementation.AElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AElementFactory.html>
SVGDOMImplementation.AltGlyphDefElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AltGlyphDefElementFactory.html>
SVGDOMImplementation.AltGlyphElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AltGlyphElementFactory.html>
SVGDOMImplementation.AltGlyphItemElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AltGlyphItemElementFactory.html>
SVGDOMImplementation.AnimateColorElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AnimateColorElementFactory.html>
SVGDOMImplementation.AnimateElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AnimateElementFactory.html>
SVGDOMImplementation.AnimateMotionElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AnimateMotionElementFactory.html>
SVGDOMImplementation.AnimateTransformElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.AnimateTransformElementFactory.html>
SVGDOMImplementation.CircleElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.CircleElementFactory.html>
SVGDOMImplementation.ClipPathElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.ClipPathElementFactory.html>
SVGDOMImplementation.ColorProfileElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.ColorProfileElementFactory.html>
SVGDOMImplementation.CursorElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.CursorElementFactory.html>
SVGDOMImplementation.DefinitionSrcElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.DefinitionSrcElementFactory.html>
SVGDOMImplementation.DefsElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.DefsElementFactory.html>
SVGDOMImplementation.DescElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.DescElementFactory.html>
SVGDOMImplementation.EllipseElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.EllipseElementFactory.html>
SVGDOMImplementation.FeBlendElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeBlendElementFactory.html>
SVGDOMImplementation.FeColorMatrixElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeColorMatrixElementFactory.html>
SVGDOMImplementation.FeComponentTransferElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeComponentTransferElementFactory.html>
SVGDOMImplementation.FeCompositeElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeCompositeElementFactory.html>
SVGDOMImplementation.FeConvolveMatrixElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeConvolveMatrixElementFactory.html>
SVGDOMImplementation.FeDiffuseLightingElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeDiffuseLightingElementFactory.html>
SVGDOMImplementation.FeDisplacementMapElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeDisplacementMapElementFactory.html>
SVGDOMImplementation.FeDistantLightElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeDistantLightElementFactory.html>
SVGDOMImplementation.FeFloodElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeFloodElementFactory.html>
SVGDOMImplementation.FeFuncAElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeFuncAElementFactory.html>
SVGDOMImplementation.FeFuncBElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeFuncBElementFactory.html>
SVGDOMImplementation.FeFuncGElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeFuncGElementFactory.html>
SVGDOMImplementation.FeFuncRElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeFuncRElementFactory.html>
SVGDOMImplementation.FeGaussianBlurElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeGaussianBlurElementFactory.html>
SVGDOMImplementation.FeImageElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeImageElementFactory.html>
SVGDOMImplementation.FeMergeElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeMergeElementFactory.html>
SVGDOMImplementation.FeMergeNodeElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeMergeNodeElementFactory.html>
SVGDOMImplementation.FeMorphologyElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeMorphologyElementFactory.html>
SVGDOMImplementation.FeOffsetElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeOffsetElementFactory.html>
SVGDOMImplementation.FePointLightElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FePointLightElementFactory.html>
SVGDOMImplementation.FeSpecularLightingElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeSpecularLightingElementFactory.html>
SVGDOMImplementation.FeSpotLightElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeSpotLightElementFactory.html>
SVGDOMImplementation.FeTileElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeTileElementFactory.html>
SVGDOMImplementation.FeTurbulenceElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FeTurbulenceElementFactory.html>
SVGDOMImplementation.FilterElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FilterElementFactory.html>
SVGDOMImplementation.FontElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FontElementFactory.html>
SVGDOMImplementation.FontFaceElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FontFaceElementFactory.html>
SVGDOMImplementation.FontFaceFormatElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FontFaceFormatElementFactory.html>
SVGDOMImplementation.FontFaceNameElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FontFaceNameElementFactory.html>
SVGDOMImplementation.FontFaceSrcElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FontFaceSrcElementFactory.html>
SVGDOMImplementation.FontFaceUriElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.FontFaceUriElementFactory.html>
SVGDOMImplementation.ForeignObjectElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.ForeignObjectElementFactory.html>
SVGDOMImplementation.GElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.GElementFactory.html>
SVGDOMImplementation.GlyphElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.GlyphElementFactory.html>
SVGDOMImplementation.GlyphRefElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.GlyphRefElementFactory.html>
SVGDOMImplementation.HkernElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.HkernElementFactory.html>
SVGDOMImplementation.ImageElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.ImageElementFactory.html>
SVGDOMImplementation.LinearGradientElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.LinearGradientElementFactory.html>
SVGDOMImplementation.LineElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.LineElementFactory.html>
SVGDOMImplementation.MarkerElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.MarkerElementFactory.html>
SVGDOMImplementation.MaskElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.MaskElementFactory.html>
SVGDOMImplementation.MetadataElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.MetadataElementFactory.html>
SVGDOMImplementation.MissingGlyphElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.MissingGlyphElementFactory.html>
SVGDOMImplementation.MpathElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.MpathElementFactory.html>
SVGDOMImplementation.PathElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.PathElementFactory.html>
SVGDOMImplementation.PatternElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.PatternElementFactory.html>
SVGDOMImplementation.PolygonElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.PolygonElementFactory.html>
SVGDOMImplementation.PolylineElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.PolylineElementFactory.html>
SVGDOMImplementation.RadialGradientElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.RadialGradientElementFactory.html>
SVGDOMImplementation.RectElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.RectElementFactory.html>
SVGDOMImplementation.ScriptElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.ScriptElementFactory.html>
SVGDOMImplementation.SetElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.SetElementFactory.html>
SVGDOMImplementation.StopElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.StopElementFactory.html>
SVGDOMImplementation.StyleElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.StyleElementFactory.html>
SVGDOMImplementation.SvgElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.SvgElementFactory.html>
SVGDOMImplementation.SwitchElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.SwitchElementFactory.html>
SVGDOMImplementation.SymbolElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.SymbolElementFactory.html>
SVGDOMImplementation.TextElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.TextElementFactory.html>
SVGDOMImplementation.TextPathElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.TextPathElementFactory.html>
SVGDOMImplementation.TitleElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.TitleElementFactory.html>
SVGDOMImplementation.TrefElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.TrefElementFactory.html>
SVGDOMImplementation.TspanElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.TspanElementFactory.html>
SVGDOMImplementation.UseElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.UseElementFactory.html>
SVGDOMImplementation.ViewElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.ViewElementFactory.html>
SVGDOMImplementation.VkernElementFactory<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGDOMImplementation.VkernElementFactory.html>


I'm quite certain now that I was truly misunderstanding the purpose of these
classes. I understand now that the proper thing to do is to use the
interfaces in org.w3c.dom.svg.

Right now I'm trying to figure out how bounding boxes work. To do this, I'm
trying to implement a simple program that will compute the bounding box of
an SVGRectElement. My code is mostly taken from the Batik documentation on
the SVG DOM API (http://xmlgraphics.apache.org/batik/using/dom-api.html),
and it is as follows:


package org.msdl.jdui.test;

import org.apache.batik.dom.svg.SVGDOMImplementation;
import org.w3c.dom.DOMImplementation;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.svg.SVGRect;
import org.w3c.dom.svg.SVGRectElement;
import org.apache.batik.util.gui.DOMViewer;

public class Test {

    /**
     * @param args
     */
    public static void main(String[] args) {
        DOMImplementation impl = SVGDOMImplementation.getDOMImplementation
();
        String svgNS = SVGDOMImplementation.SVG_NAMESPACE_URI;
        Document doc = impl.createDocument(svgNS, "svg", null);

        // Get the root element (the 'svg' element).
        Element svgRoot = doc.getDocumentElement();

        // Set the width and height attributes on the root 'svg' element.
        svgRoot.setAttributeNS(null, "width", "400");
        svgRoot.setAttributeNS(null, "height", "450");

        // Create the rectangle.
        //Element rectangle = doc.createElementNS(svgNS, "rect");
        SVGRectElement rectangle =
(SVGRectElement)doc.createElementNS(svgNS, "rect");
        rectangle.setAttributeNS(null, "x", "10");
        rectangle.setAttributeNS(null, "y", "20");
        rectangle.setAttributeNS(null, "width", "100");
        rectangle.setAttributeNS(null, "height", "50");
        rectangle.setAttributeNS(null, "fill", "red");
        SVGRect bbox = rectangle.getBBox();
    }
}


Unfortunately, rectangle.getBBox() consistently evaluates to null. I think
the reason for this might be alluded to in the documentation on the SVG DOM
API, when it states that, "Though the DOM implementation of Batik is an SVG
DOM implementation, the SVG-specific methods that rely on the document
having been rendered (particularly geometry related methods, such as
SVGLocatable.getBBox<http://xmlgraphics.apache.org/batik/javadoc/org/w3c/dom/svg/SVGLocatable.html#getBBox%28%29>)
cannot be used at this point."

My question is, what do I need to do to make the getBBox method work? If I
need to render the document, is it possible to minimally do so in order to
simple retrieve the Element's bounding box, or is it necessary to fully
render the document in, for example, JSVGCanvas in order to make getBBox
work?

Also, as a sidenote, I was looking up the javadoc information on the
interfaces in org.w3c.dom.svg, and I discovered that the Batik javadocs link
to several classes in org.w3c.dom.svg, but these links appear to be dead.
For example, you have:
*SVGOMElement<http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGOMElement.html>
*        This class implements the
SVGElement<http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/svg.SVGElement.html?is-external=true>interface.
But SVGElement<http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/svg.SVGElement.html?is-external=true>takes
you to someplace dead. Also, going up the directory tree takes you to
here:
http://www.w3.org/2003/01/dom2-javadoc/
But, these javadocs do not show an svg package in org.w3c.dom.
I searched a bit more and was unable to find any "official" javadocs for
org.w3c.dom.svg. I ended up just pulling org.w3c.dom.svg out of CVS and
generating my own javadocs. Does anyone know where the official javadocs for
these interfaces are?

I would greatly appreciate any guidance anyone can offer.
Thanks.

Jake

Re: introducing myself, and a few questions

Posted by th...@kodak.com.
Hi Jake,

"Jake B" <ot...@gmail.com> wrote on 08/22/2007 11:20:50 PM:

> The goal is to take a meta-modelling environment which we
> have implemented in Python/Tkinter, construct a lightweight front-
> end, and use pieces of the original environment to power the back-end. 

    Well I hope it goes well for you, and hopefully we will be able
to help you past any rough spots.

> I'm currently working on a small prototype in order to get familiar 
> with Batik, and become a bit more knowlegable about the details of 
> the technologies involved. Basically, I am trying to construct a few
> basic user interface widgets (a button, a panel, and a menu) in SVG.
> I know that the idea of building standard user interface widgets has 
been 
> discussed, and even implemented, but my version will have a slightly
> different twist to it, which is that the layout and reactive 
> behavior of the widgets will be modelled using statecharts (our tool
> can generate executable python code). This statecharts will be kept 
> on the server. The goal of this prototype is to show that widget 
> behavior can be modelled using statecharts, and to get aquainted 
> with the technologies that the rest of the project will rely upon. 
> 
> That's pretty much the gist of what I'm trying to do. I have a few 
> question to start out. These are fairly open questions, and there 
> may not be a straightforward way to answer them, or a single correct
> answer, but I would nevertheless appreciate any advice anyone could 
offer: 
> 1. In the context of the SVG specification, what would be the most 
> appropriate way to represent a widget? It would either have to be a 
> <g>,<svg> or <symbol>. I think any of these would work, but I'm not 
> sure which one would be the truest to the spec. 

   I would tend to use a 'g'.  The advantage of 'svg' (and also symbol)
is that it establishes a viewport which first adds a default clip region
(which could be good or bad) and second gives you some fairly simple
control of the coordinate system.  That said you actually have more
control over the coordinate system with 'g' since you can use the 
transform
but the interface is a bit more complex.

   Symbol is useful if you want to have multiple copies of the 
_exact_ same thing.  As soon as you start creating tweaked versions of
things to add as 'symbol' elements that you then 'use' you are almost
always better off just adding the tweaked elements where the use would 
be.

> 2. In the context of extending Batik, what would be the most 
> appropriate way to represent a widget? If, for example, in the SVG 
> spec, a widget would best be represented as <g> element, then in the
> context of Batik, would the most appropriate way to represent a 
> widget be to create a subclass of SVGOMGElement? Or would there be a
> better way? 

    Don't subclass our DOM Elements unless you want to create custom
DOM Elements.  I would probably build a separate 'widget tree' with
your own classes (not directly tied to DOM).  Then I would have 
references to the DOM tree in my widget objects.  The widget objects
would register callbacks on the DOM objects for events they care about.

    If you need to you could also have a hash table that allowed one
to go from an arbitrary DOM object to the associated Widget Object
but in my experience that isn't normally needed (the event listeners
know what object registered them, so this generally only needed if
the need to map graphics->widget comes outside of the scope of an
event).

> 3. I'd like to leverage the Factory classes in org.apache.batik.dom.svg
> , but I can't figure out how to initialize the attributes of the 
> Element objects I've created. They do not have public set methods, 
> and even though they implement the Element interface, calling 
setAttributeNS
> on them does not change their attributes. What is the proper way to 
> set the attributes on these objects?

   What Factory classes in batik.dom.svg?  The only two I see are the
Factory classes for producing Documents.  Documents don't have
attributes - so perhaps that is your problem?

   A clean Application should never even know that batik.dom.svg
exists.  That is the package we use to implement the org.w3c.dom.svg
interfaces.  The org.w3c.dom.svg interfaces are what you should
use in your Application.  We are free to change any and all details
of our DOM implementation - but the W3C SVG DOM interface must stay.

> 4. I also cannot seem to append the Element objects produced by the 
> factory classes to the SVG document by calling 
svgRoot.appendChild(object). 
> It just doesn't seem to get appended to the DOM tree. Is there a 
> special way to attach the objects created by the factory classes (as
> opposed to those created by doc.createElementNS) to the DOM tree?

   I suspect you are creating Document objects which can't be
'child' Nodes.  The only correct way to create Element's is through
the document object.  Our Document Object is cleanly extensible
so you can register new 'factory' methods to construct private DOM
Objects.  However, as I said above I would lean towards leaving the
DOM the DOM and hang my data structures alongside the DOM.  This
might also make the job of sending updates a little easier as your
control stuff won't be mixed in with the 'display' document.
 
> Thank you very much for reading my very long email. I would 
> appreciate any guidance anyone can offer.

   Good luck.

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