It looks like SVG is the flavor of the month, so let me take a crack
at answering all the questions together in one go.
Mark Fortner said:
> I'm working on ArgoPrint and one of the needs that we have is to generate
> "clickable" Figs. This would make it possible to add links to objects in
> the SVG diagram to documentation about those objects. From an API
> perspective this might look like this:
>
> SVGWriter writer = new SVGWriter(outputFile);
> writer.setLinkTemplate("<a href=\"somewhere.com/objId=%s\">%s</a>", new
> String[]{objectId, objectSvgFragment});
>
> The last line would allow a developer to surround an object with a link.
>
> Is anyone considering this type of use case in the proposed re-write of
> SVGWriter?
Tony Rogers followed separately with :
On Thu, Jan 22, 2009 at 12:54 PM, Anthony Rogers <[email protected]> wrote:
> I recently exported a pretty simple diagram for one of my personal side
> projects in order to open the image in other programs and fine-tune its
> appearance. When I examined the XML, however, I discovered that a pretty
> straightforward Class Diagram was a nightmare of chaotic SVG.
>
> Couple of questions I have in response to this:
>
> Before exporting a diagram, is ArgoUML managing the diagram's images as SVG?
> Or, is it stored in some other format and then transformed into SVG at the
> time of export?
> I checked the Cookbook ยง5.3. Diagrams in order to find out how ArgoUML is
> generating its SVG code, but I saw nothing about SVG in this part of the
> documentation. I looked a few other places in the Cookbook as well with no
> luck. Is the component that generates SVG documented? If not, could someone
> point me to the code that is responsible for it?
ArgoUML's graphics are managed by a separate component called GEF
(Graph Editing Framework or some such). It was implemented by
undergraduate CS students supervised by a grad student using the
graphics technology that was available in Java 1.1. It uses integer
coordinates, thinks all lines are 1 pixel wide, all colors opaque, and
that almost no one would use any color except black or white. It's
never heard of alpha channels, gradients, fill patterns or a myriad of
other very basic graphic technologies. The only reason I'm mentioning
this is to give everyone an idea of the starting point and make you
realize that it's lucky there's even an SVG exporter to start with.
One likely reason that there's nothing in the cookbook about SVG is
that it's all done by GEF. All ArgoUML does is tell GEF "make SVG"
and it does it however it wants. In this case, "however it wants" is
SVGwriter which extends the Java class "Graphics" that implements the
simple Java 1.1 graphics primitives (drawLine, fillRect, etc).
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Graphics2D.html It
then takes the diagram and "draws" it onto this pseudodevice which
takes the drawing commands and generates SVG from them (fortunately
the SVG drawing model and the Java drawing model are very similar).
Now this is all kinda primitive, but I'm not sure it qualifies as a
"nightmare" (at least it's anything like the nightmares *I* have).
Mark's request for a way to add links was something which I originally
thought would be difficult, but, on reflection, I think it could be
done with a little restructuring of things. Basically what's needed
is a way to know when top level figs begin and end from a drawing
point of view. This would allow them to be put in their own SVG group
(which would satisfy some other complaints in the bug database about
not being able to manipulate figs as a unit) and then wrap the whole
thing in a SVG <a> element for the link.
Currently the default drawing mechanism is used with loops that look
something like
for (Layer layer : diagram.getLayers()) {
for (Fig fig : layer.getFigs()) {
fig.paint(svgWriter);
using a separate implemented which used something like the following
in the inner loop would probably do the trick
svgWriter.beginFig(fig);
fig.paint(svgWriter);
svgWriter.endFig(fig);
Now, as for the nightmares, they can be difficult to make go away, but
depending on the type of nightmare, groups might provide some relief
there too. One of the things I noticed is that the drawing colors are
repeated for every element. Using nested groups with a minimal change
algorithm to only tag new groups with the attributes that have changed
could go a long way towards making the SVG output less verbose and
easier to modify at a small expense in code complexity. BTW, I don't
think the original author was just being lazy. There are some
comments in the code which seem to indicate a mistrust of the SVG
renderers of the era, which could be why everything is always fully
specified -- to make the renderers' job easier and less error prone.
Mark opened a new bug report with his request(s). I'd suggest that
Tony describe his nightmare in a bug report as well and propose what
he'd like to see done differently.
BTW, I've got a rewrite of GEF's SVGwriter called SvgWriter2D which
upgrades it to support Graphics2D, the Java 1.2 addition which brought
Java graphics into the modern world, and I plan to experiment with
some of the ideas that I've mentioned in that context, so that should
provide some information on the feasibility of this stuff.
Tom
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1043441
To unsubscribe from this discussion, e-mail:
[[email protected]].
