Thompson, Bryan B. wrote:
Hello,
I am exploring the notion that I could use batik to support a graph layout
algorithm based on minimizing constraint error. Notionally, I would like to
define reusable graphical patterns and apply them to sections of a directed
graph based on characteristics associated with the nodes and edges of that
graph. At the moment I am thinking in terms of RDF descriptions of the
directed graph, but I am also interested in visualizing UML using a similar
approach.
Layout requires iterative positioning of the origin of graphical elements
whose size is not known until the bounding box of the element has been
computed. This has led me to think of batik as a platform in which
parameterized svg subgraphs could serve as patterns. When instantiated, the
size of the subgraph could be computed. Subgraphs that are peers within a
larger graph would then be laid out according by minimizing constraint
error.
So, the layout algorithm would need to be able to compute the size of
graphical elements, but it would not need to go as far as rendering those
elements graphically. The output would be an svg document (not a rasterized
image) comprised of the instantiated patterns in which the subgraphs were
aligned to origins that minimized constraint error. The svg document could
then be delivered to a browser or rasterized as necessary.
I would appreciate any advice on whether or not batik is well aligned with
solving this problem and any suggested approaches in terms of the batik
architecture.
Batik implements much of the extended SVG DOM in particular
the SVGLocatable interface which can give bounding box information.
In order for these API's to work however you do need to build the
rendering tree (we call it the GVT) as this is where this sort of
information is available. In GVT you can also get more detailed
information about a group of elements, such as the 'outline' of
the group, but this is not directly exported through the DOM
interfaces.
Once rendering tree is built it is autmatically kept in
sync with the DOM tree, so you can for example change the
x/y/width/height attributes on a rect and if you ask for the rect's
bbox again it will reflect the change in x/y/width/height.
In regards to the symboligy portion of your query you may
want to look at the 'use' and 'symbol' elements in SVG as they
would appear to be ideal for your needs.
I would say that Batik is probably well aligned with your
needs if you need an engine that can compute the bounds of complex
objects in a flexible way. It may be significantly larger than
what you really need (you could always just have some additional
metadata with your 'symbols' - or always require your symbols to
provide a viewbox in which case you wouldn't need Batik to do
bounds calcs at all).
Thanks for any advice,
-bryan
Bryan Thompson
Systems Architect
Hicks & Associates, Inc.
3811 N. Fairfax Drive, Suite 850
Arlington, VA 22203
+1 703-469-3409 (o)
+1 202-285-5099 (c)
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
