Generating & Rendering SVG

I am thinking of a site that will generate images of quotes.

The first thing I think of is of course SVG, and I did a “dry run” for the use cases.
(should discuss the drawbacks later, as an anti XML guy. For my usage it should be clean enough)

Some points to note:

It is natural to use Javascript to interact with it.


Manipulating SVG Documents Using ECMAScript (Javascript) and the DOM

Libraries to interact with

Article on svg javascript libraries

svgweb uses flash to support compatability. Sound weird for me now.

Processing.js. Library for data visualization. seems suitable mostly for scientific computations.

SVG Image library and Editor provide a library of SVG images and a nice SVG editor which can export to code/png.

It require sign up to save the image on web.

No Save As – way to render as normal img

Using SVG to render the image, user can hardly save as an image using the usual right click menu way, which is crucial to my site

<br /> var canvas = document.getElementById("mycanvas");</pre>
var img    = canvas.toDataURL("image/png");

another version:



window.onload =function(){

var canvas = document.getElementById("canvas");

var context = canvas.getContext("2d");

context.fillStyle ="green";


// no argument defaults to image/png; image/jpeg, etc also work on some

// implementations -- image/png is the only one that must be supported per spec.

window.location = canvas.toDataURL("image/png");



Generate Link to save the data, avoiding round trip to server

You can avoid a round trip to the server.

Base64 encode your SVG xml.

Then generate a link to that data. The user can right click on to save it locally.

// This example was created using Protovis &amp; jQuery

// Base64 provided by <a href=""></a>

function encode_as_img_and_link(){

// Add some critical information

$("svg").attr({ version: '1.1' , xmlns:"<a href=""></a>"});

var svg = $("#chart-canvas").html();

var b64 = Base64.encode(svg);

// Works in recent Webkit(Chrome)

$("body").append($("&lt;img src='data:image/svg+xml;base64,\n"+b64+"' alt='file.svg'/&gt;"));

// Works in Firefox 3.6 and Webit and possibly any browser which supports the data-uri

$("body").append($("&lt;a href-lang='image/svg+xml' href='data:image/svg+xml;base64,\n"+b64+"' title='file.svg'&gt;Download&lt;/a&gt;"));


The img tag works in Webkit, the link works in Webkit & Firefox, and may work in any browser which supportsdata-uri

Annotation & AST

Come up with them when I am battling with the JBehave GIVEN-WHEN-THEN core.

style of more and more annotations is getting popular. while to define them may not be a very simple task

Groovy way to define annotation for ast transformations

AST is the tree of java source code, what behind eclipse’s validation, content assist, F3 and everything

These two articles combined is a very nice introduction to the annotation concept and AST, a little bit “advanced” but important for junior java / groovy programmers


Build is hard
Development is hard. While build is even harder.

It is always there as a big obstacle. From my experience, optimistically, 30% of development effort are wasted in build and environment configuration, at least for a junior developer.

Your eclipse installation fail, a plugin not working, EOL is of windows instead of linux. SVN wrongly cached.
Class path of build and test are different, Spring application context file cannot be loaded…

Ant is a great tool. Maven is another one, together with tool like brew, easy_install, all great tools.
However those stuff never worked seamlessly for me in most scenarios. Dependencies can’t be resolved, version conflict, proxies…etc

Forget about environment config, we all understand the important of a quick build. Faster build also implies faster test.

Jenkins is the best open source framework for automated continuous integration. There are lots of features and possibility besides build.
Still, there is a need for build language.

Ant & Maven could be better
For Ant & Maven, both of them are great but they have their own problems. Therefore I am glad to introduce a new one, below, Gradle.

1) Both Ant and maven use XML

Although schema validation is good, XML is hard to read or configure, also heavy weight.

2) Maven lifecycle is complicated

Maven features

Differ from Ant that maven has several important features, including dependency management with repository library and lifecycle.

Firstly, there is a learning curve for this, and secondly this limited the expressiveness of the language as maven enforce its life cycle rules to its project. Some tasks are tedious & procedural and they are. With maven syntax it will be hard to express them.

Here is a nice post on Maven Alternatives.


Back to the topic, Let’s talk about Gradle then.

To be honest I am not expert in Ant nor Maven. However I can say Gradle is at least more intuitive to me.

As people put it, it can be considered as Groovy, Ant , Maven, Ivy combined
Gradle features

1) Nice DSL

Gradle is written in Groovy and borrowed a lot from groovy.
However user are neither required to be a groovy developer or required to run it in platform with groovy dependency.
Basically all features can be expressed well in the Domain Specified Language (DSL) itself.
You are essentially writing groovy but you required only to write about the domain, which are those build tasks, dependencies, specification, without need of knowledge in groovy.
I would say compared to XML, DSL is a much  better choice.

2) Really good documentation
Really clean and clear documentation for such a new tool. I encountered some gotchas, but still that is minimized.
Cool enough, the documentation itself is build using gradle. (I just remember coffeescript is compiled by coffeescript)

3) Dependency Management

I never use Ivy, in Gradle dependencies will be formed a DAG (Directed acyclic graph) and resolved accordingly.

4) Ant & Maven features with maven Convention

It is possible to execute ant task. It is also possible to fetch artifacts from maven repository. Not possible to execute maven command though.For maven convention, this is the right decision. Most projects are using Maven layout. Most developers are used to maven layout. Yes, convention over configuration helps.

5) Active development 

I consider this an important factor when I was picking any framework
Active Developing most of the times implies an active community, which then imply you get help easier.
It also means bugs will get fixed, features will be added right there.

6) Wrapper to build in places even gradle not installed.
The wrapper will resolve all the dependencies, installing gradle to the target. No problem to take the artifact to build in windows or linux.

There are more. Nice API, profiling, numerous plugins including OSGI. The biggest drawback is perhaps there is no eclipse plugin yet.
Syntax validation using groovy editor is error prone.

After all, this is build tool for tomorrow, and,  today.

I also see the potential for writing integration test scripts with this tool.

There exist a integration testing framework, GINT which used GANT , another build alternative writing in Groovy, as test scripts.
It turns out that Gradle & GANT are quite similar in this context, while GANT focused on scripting with no dependency management or extra features. Gradle could  be a much more powerful replacement.
will talk about some real code with gradle and some gotchas later