[email protected]
[Top] [All Lists]

Getting to know Batik's codebase

Subject: Getting to know Batik's codebase
From: Cameron McCormack
Date: Tue, 1 May 2007 14:11:42 +1000
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

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

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

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


Cameron McCormack, http://mcc.id.au/
        xmpp:[email protected]  â  ICQ 26955922  â  MSN [email protected]

[email protected]----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

<Prev in Thread] Current Thread [Next in Thread>