using batik to support graph layout

["Thompson, Bryan B." <BR...@saic.com>]

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.

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)
thompsonbry@saic.com

Re: using batik to support graph layout

[Cameron McCormack <cl...@csse.monash.edu.au>]

Hi Bryan.

Thompson, Bryan B.:
> 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.

I am currently working on a project to incorporate one-way constraints
into SVG, in particular, into Batik.  You can have a read about the
project here:

  http://www.csse.monash.edu.au/~clm/csvg/

One of the aims of the project is to be able to embed complex layout
logic inside the document itself, by having attributes be evaluated
expressions.  One way constraints are probably not good enough for your
iterative methods, but the project may be of interest to you anyway.
The project isn't nearly complete yet, and probably won't be for a good
few months.

Of course, though, writing a program which used Batik to display an SVG
document tree that you generated would work quite well.

Cameron

-- 
Cameron McCormack
  // clm@csse.monash.edu.au
  // http://www.csse.monash.edu.au/~clm/
  // icq 26955922

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

Re: using batik to support graph layout

[Thomas DeWeese <Th...@Kodak.com>]

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)
> thompsonbry@saic.com
> 
> 
> 




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