Friday, 27 August 2010

Page Breaks/Layout in Diagramming Applications

Is it just me that hates them? Every time I run up the Java Swing version of GraphEditor the first thing I do is remove the page layout. What's the point of restricting the amount of available space the moment you start an application, is the idea to make sure the printed version comes out correctly? If so, with laptops and tablets now commonplace in meetings (printing from an iPad would be nice Apple), I suspect printing is in decline. Corporate environmental policies tend to see to that, as well. The other thing is, isn't the computer supposed to deal with details like this for us? How about diagramming application default to maximum screen size by default and intelligently sort out printing for us (by which I mean avoid vertices and text being split between pages and zooming as appropriate)?

Friday, 20 August 2010

PNG embedded diagrams

In the previous post I mentioned embedding the XML of mxGraph models into PNG. The PNG specification includes a zTXt element, which enables very large sections of compressed text to be placed in the PNG encoding. mxGraph and onwards contain functionality to embed the model XML in created PNGs and to decode PNGs created in this way, using the Java code base. The GraphEditor example of the Java Swing client now saves in this PNG+XML format (.png suffix) by default to demonstrate the idea. We felt this is a somewhat more intuitive way of storing and transferring diagrams than text XML, since suddenly every user has the tools to look at the diagram, without the need for mxGraph. It provides a simple means for the server side to display diagram thumbnails without having to process the diagram and removes the necessity to synchronise XML formats and their associated images.

You can still stick with text XML if you prefer, but we'll sulk if everyone doesn't use this shiny new feature. This does bring up the issue of whether the JavaScript display looks the same as the generated server diagram. By default, they are identical, but customisation of the JavaScript can cause duplication of implementation on the server technology to get image generation to look the same. The majority of cases where this occurs happen because of new shapes being added to the JavaScript client programmatically. Which is another important reason for adding the stencils mentioned in the last post.

We are going to add an additional option to add the text without compression, not everyone will want their servers unzipping every time a diagram is opened and it provides a mechanism to view and extract the XML using a text editor, if required. Given the text is likely to form the minority of the file size, we're inclined to make this the default save format.

If you have other cases where there is code duplication necessary (other than I/O), we'd be interested to hear.

Tuesday, 3 August 2010


We recently updated the Java shapes architecture to match the JavaScript implementation. It's better, but still not quite right (so apologies to Java Swing users for another API change, although, we think it might be possible to avoid one).

The improvement is to add stencils, exactly in the same way an application like Visio has them. It's not a rocket science idea, but clearly a big improvement in usability for both developers and users. We'll supply a central repository of a good number of stencils, which will be freely available under a creative commons style license. You'll be able to load one, or a set, and work with it as you would any under shape.

There are some details to be worked out, the registry system, a naming convention, etc. But, we've got the first version working in Java, so we're looking at a first release in the Java code base September-October 2010. We didn't want to invent our own description XML for stencils, and the Visio format is far too complex for our purposes, so we've gone with the shape format available on the excellent Dia diagramming tool. This is an SVG sub-set, wrapped by a few additional attributes needed. The format is clearly well thought out, enables the vast majority of required stencils to be drawn, yet keeps the format simple and fast to implement.

Dia also specifies a mechanism to define a set of stencils, we'll be using this, or something very similar. We'll also be re-using our embedded PNG concept we recently introduced to the Java code ( which is a posting on its own, and probably deserves a post after this one, since it needs a proper explanation ). The short story is that a set will comprise a set description XML and some number of PNG files only. The Dia format describing the XML of the shape will be embedded in the PNG itself.

As mentioned, the change to the API should be minimal (if anything). We intend to add the stencil as a new shape and change the other vertex shapes to call the correct stencil ( but leave the old shape classes and methods, only deprecated in Java ).

The additional ideas this project has brought up are: 1) Implement the edge end markers as stencils and 2) Implement a vertex perimeter description to position ports correctly. We're researching a mechanism to infer the perimeter from the SVG of the shape, but this is very much at the research stage.

In summary, the first release will be a test to see how developers find the idea in the Java client, after that to port the concept to the JavaScript client, once the design is finalised. We're looking at December 2010 for the JavaScript production version, assuming some number of iterations on the Java code.