Just another quick comment to throw into the works (not a suggestion but an option)
As Mark Fortner has suggested previously we could use a template language to generate the SVG. GEF already has an SVG.tee (tee files are GEFs own template language) but I have no idea as to its completeness or accuracy. Should anyone go this way I'd prefer to see Velocity, Freemarker or Jamon used. We use GEF's tee file mechanism historically for PGML but if we start on something else I'd rather use something less proprietary than tee files. Regards Bob 2009/1/22 Anthony Rogers <[email protected]>: > Hey Tom, > > Thanks for the comprehensive reply! My comments follow… > > Tom Morris wrote: > > 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. > > > I was afraid the situation was something like that. :) > > 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). > > > Good to know about why it's not mentioned in the Cookbook. May I suggest > that the Cookbook be edited to at least mention GEF? Perhaps something > similar to what you've got above? > > Regarding the Java classes, I have a rudimentary understanding of Java > basics, but not of Java's classes and libraries and whatnot. Still, I'll > check out that URL and see if I can understand anything. > > 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). > > > Hahaha! :) I'm sorry if I stepped on anybody's toes with that comment. > > It's a nightmare for me as an XML junkie. I've been playing and reading and > writing primarily XML for the past couple of years, and before that I was a > standards-compliant XHTML + CSS junkie. So, as someone who has practiced > writing markup that is as semantic as possible for years, and as someone who > has enjoyed the ease with which simple, clean, semantic markup may be styled > with CSS to very powerful effect—that's why I used the term nightmare. > > Again, no offense intended. Sorry, GEF authors. > > 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. > > Nested groups would be a great improvement over the currently extreme > redundancy. But the nested groups approach is not necessary with CSS, and > may possibly inhibit the ability for CSS to be applied to an SVG export. > > I'm not trying to be difficult to those of you who aren't familiar with CSS, > but that is one of SVG's main attractions. Again, I don't know Java > terribly well, but if anybody is interested, I'd be happy to collaborate and > explain the kind of output that would be ideal for use in other XML & CSS > editors. > > 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. > > > Yeah, that makes sense. I harbor no ill will to the author for creating > something appropriate for his time. :) > > But it's 2009 now, dammit! I think Argo can do much better. > > 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. > > > I filed a bug report (Issue 5650). Thanks for your help! > > —Z ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1043495 To unsubscribe from this discussion, e-mail: [[email protected]].
