Hi guys.
Hope you’re having a relaxing “interim period”. :)
I’d like to make sure you both have a good feeling of Batik’s codebase
and have started to refine your designs before the coding time starts,
on May 28.
Have you checked out the source and started to have a poke around? Here
is a very brief overview of (the relevant parts of) Batik’s
architecture:
▪ the SVG DOM (org.apache.batik.dom.svg)
These classes implement the SVG DOM. Most of the classes in this
package are named SVGOM*Element, and derive (eventually) from
org.apache.batik.dom.AbstractNode, which implements
org.w3c.dom.Node. Other classes in this package are for the SVG
datatypes, such as SVGOMAnimatedLength (which is an implementation
of org.w3c.dom.svg.SVGAnimatedLength).
▪ the GVT (org.apache.batik.gvt)
The GVT is the Graphics Vector Toolkit (I think!). It’s a
collection of classes that can represent graphical objects in a
tree-like fashion, which mostly parallels the structure of the SVG
document. For example, for a ‘rect’ element in the document, which
is represented by an org.apache.batik.dom.svg.SVGOMRectElement
object, there will be a corresponding org.apache.batik.gvt.ShapeNode
object that represents the rectangular shape and its properties.
A GVT tree is usually rooted by a
org.apache.batik.gvt.CanvasGraphicsNode. Each GraphicsNode can be
painted to a Java2D java.awt.Graphics2D object, which is how objects
get painted into the JSVGCanvas component.
▪ the bridge (org.apache.batik.bridge)
The bridge classes are used to build (and keep in sync) GVT objects
from the SVG DOM objects. The main class that runs this process is
org.apache.batik.bridge.GVTBuilder. Each SVG DOM object has a
corresponding bridge class, for example there is the
org.apache.batik.bridge.SVGRectElementBridge, which is in charge of
building a ShapeNode from the SVGOMRectElement object.
Each document has an org.apache.batik.bridge.BridgeContext, which is
a central point of document handling that the different bridge
classes will use.
▪ the CSS engine (org.apache.batik.css)
The CSS engine implements the style handling rules in a document.
As well stylesheets and inline style with style="" attributes, the
SVG presentation attributes (such as fill="" and font-size="") are
handled by the CSS engine. Whenever a bridge object needs to get
some styling information when building a GVT object, it’ll query the
CSS engine for the property’s current value. For example, see the
org.apache.batik.bridge.AbstractGraphicsNodeBridge#buildGraphicsNode
method. (AbstractGraphicsNodeBridge is the base class for all
bridges that create an org.apache.batik.GraphicsNode—basically, for
all graphical SVG elements. It calls some methods in CSSUtilities
(which in turn queries the org.apache.batik.css.engine.CSSEngine
object) for values of various properties, such as 'opacity' and
'clip-path'. These property values are then set on the
corresponding GraphicsNode object.
▪ the animation engine (org.apache.batik.anim)
The animation engine classes are responsible for “ticking” the
document and modifying the relevant SVG DOM objects representing
attributes on SVG elements (or the relevant CSS properties, if it’s
an attributeType="CSS" animation).
The classes in org.apache.batik.anim.timing handle all of the timing
requirements of SMIL Animation (begin/end/dur/repeat/etc.
attributes), and classes in org.apache.batik.anim.values represent
values in the animations of the various types (numbers, colours,
lengths, length lists, etc.). The classes that represent each
individual animation are org.apache.batik.anim.*Animation.
org.apache.batik.anim.AnimationEngine (and its specialisation,
org.apache.batik.bridge.SVGAnimationEngine) is the main driver of
animations in the document. It handles adding and removing
animations, ensuring they will be evaluated in the correct order,
and update each animated attribute/property every “tick” by querying
each *Animation object for its current value based on the current
document time.
▪ the JSVGCanvas (org.apache.batik.swing)
This is the SVG viewing component that’s used in the main part of
Squiggle. It is essentially a component that can have a GVT tree
rendered on it, which also kicks off the bridge objects to generate
that GVT tree from an SVG document.
▪ the DOMViewer (org.apache.batik.util.gui)
The DOMViewer class which you’ll probably be interested in seeing is
just a Swing component that inspects the current state of the SVG
document and represents it with a tree along with a table of
attribute/property values.
Obviously this’ll be a lot to digest if you’re new to the code. I
suggest you trace through a rendering of a document to see how the flow
of control works between all these classes. A good place to set your
IDE up to break on might be
org.apache.batik.swing.svg.AbstractJSVGComponent#installSVGDocument.
I think it’ll be good for you guys also to have a look through the SVG
1.1 spec (http://www.w3.org/TR/SVG11/) if you haven’t done so already.
As always, just ask on the batik-dev mailing list if you have any
questions.
Are you guys going to have a wiki or blog or something to document your
progress? There’s no requirement to, but it may be useful for me (and
the other devs) to see where you’re at.
In a few weeks, before the coding start date, we can discuss the
logistics of how your code is going to be added in to the existing
codebase (a series of patches, a branch, directly in the trunk, or
whatever).
Cameron
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
