vectomatic » SVG

Availability of lib-gwt-svg 0.5.4 and other announcements

admin — Wed, 02 Nov 2011 21:25:16 +0000

I am releasing a new version of lib-gwt-svg. For a detailed list of changes, see the release notes. This new version is mostly a bug-fix and tuning release, which provides better support for IE9 and Opera. Among the notable features of the release are:

On IE9, the XPath APIs are now supported. This is made possible by embedding the xpath.js library by Cameron McCormack, which provides the XPath support lacking in IE9 and IE10. Other browsers, which have native xpath support are unchanged and do embed xpath.js.
On IE9, stylesheets embedded in dynamically loaded SVGs are not ignored any more (found a workaround for this IE9 bug)
On Opera, xlink hrefs embedded stylesheets contained in dynamically loaded SVGs are not broken any more (found a workaround for this Opera bug)
On all platforms, OMSVGParser.parse will throw a ParserException in a consistent manner when fed input which is not well-formed or is not an SVG document

I have created a new XPath sample in the lib-gwt-svg-samples program. It lets you type xpath expressions which are evaluated on the fly, resulting in the proper nodes being selected in the SVG and XML view of a sample document.

I have updated all my educational games to use the latest version. The following matrix shows what works and what does not, per platform:

	Webkit (chrome)	IE
samples-shapes
sample-events
sample-parser
sample-widgets
sample-xpath
sample-smil	(No JS SMIL support)	(No SMIL support)
games-chess
games-dots	(No JS filter support)	(No filter support. Coming in IE10)
games-maze
games-push
games-puzzle

SVG paint and stroke

admin — Sat, 10 Sep 2011 08:58:11 +0000

The SVG standard provides a complete API to deal with various forms of paint (rgb colors, named colors, linear gradients, patterns, …) and this API integrates tightly with the CSS APIs to provide programmatic access to the various characteristics of the paint. The dash-array CSS property can also be introspected with the same CSS APIs.

In real web development however, things are not as easy as they should, because almost all browsers fail to implement correctly if at all at least some part of the specification. This is why I had not tried to incorporate this part of the specification in lib-gwt-svg so far.

If things were perfect, all one would have to write to access a color or the dash-array attribute would be:

var circle = document.getElementById('c1');
var paint = circle.style.getCSSPropertyValue('fill');
var green = paint.rgbColor.green;
var greenValue = green.getFloatValue(green.primitiveType);
var dash1 = circle.style.getCSSPropertyValue('dash-array').item(0);
var dash1Value = dash1.getFloatValue(dash1.primitiveType);

In the real world, the code above does not run well in most browsers:

Browser	Result
Firefox 4+	getCSSPropertyValue works only for computedStyle, not style
Chrome 14+	Works correctly
Opera 10+	Not supported (exception thrown)
IE9+	Not tested

In version 0.5.3 of lib-gwt-svg, I have developed a few classes to emulate most of the behavior of SVGPaint and CSSValue and map it to GWT. The implementation is based on parsing the css text value of the css properties to create a small graph of objects representing the color. The shortcoming of this approach is that this graph is an emulation: changing it will not affect the original CSS property. With this restriction in mind, it is now possible however to write applications which manipulate SVG paint and dash arrays, in a portable way. If browser implementations make enough progress, I plan to switch to the native implementation.

Here is sample code which uses it:

OMSVGCircleElement circle = (OMSVGCircleElement)OMSVGParser.currentDocument().getElementById("c1");
OMSVGPaint paint = (OMSVGPaint)circle.getStyle().getSVGPropertyCSS(SVGConstants.CSS_FILL_PROPERTY);
OMRGBColor green = paint.getRgbColor().getGreen();
float greenValue = green.getFloatValue(green.getPrimitiveType());
OMCSSValueList dashArray = (OMCSSValueList)circle.getStyle().getSVGPropertyCSS(SVGConstants.CSS_STROKE_DASH_ARRAY_PROPERTY);
OMCSSPrimitiveValue dash1 = (OMCSSPrimitiveValue)dashArray.getItem(0);
float dash1Value = dash1.getFloatValue(dash1.getPrimitiveType());

To conclude this post, here is a pointer to the javadoc documentation of this API.

Annoucement: lib-gwt-svg 0.5.1 availability and other miscellaneous changes

admin — Tue, 22 Feb 2011 08:30:51 +0000

This post summarizes changes and new features to vectomatic and lib-gwt-svg.

lib-gwt-svg
A new version 0.5.1 is introduced, to provide formal support for GWT2.2.0. It is mainly a bug-fix and improvement release, but it contains a large number of fixes (see the release notes for details). It is available through the usual channels: maven central repository, vectomatic website, and google-code project.

lib-gwt-svg-samples
The samples for lib-gwt-svg have been revamped too (version 0.5.2) to finish the work started on CSS and SMIL animation. The SMIL animation sample now works as expected (on FF4 and Opera). The widgets sample layout has been redesigned to demonstrate scalability of widgets.

lib-gwt-svg-edu
Additional new GWT projects have been created to make the games available as Opera Widgets and KDE Plasmoids. The Opera Widgets are already functional, the KDE plasmoids not yet. More work is still required though on the CSS front to make the game appearance and responsiveness adequate for use on mobile devices. Thus the widgets are not yet published on the Opera repository.

Repository structure
The unified SVN repository structure which contains all vectomatic projects is going to be split in several parts. The reason is that it is becoming difficult to synchronize the release of all these projects into one big meta-release and that they will evolve better if they can have a lifecycle of their own. The plan is to have at least three repositories:

a repository dedicated to the general purpose library lib-gwt-svg / lib-gwt-svg-samples
a repository dedicated to games (lib-gwt-svg-edu-* / lib-gwt-svg-chess)
a repository dedicated to a SVG editor application (vectomatic2)

The vectomatic2 development has already been extracted to a private svn repository and is receiving intensive care. A new project (with a new name) will be created and announced shortly to host it.

IE9 and lib-gwt-svg

admin — Thu, 18 Nov 2010 21:49:37 +0000

A first (small) step has been made on the way towards running lib-gwt-svg apps into IE9. I have done some tests with the latest code available (called “platform preview 7″). The good news first: a few of the tabs in lib-gwt-svg-samples work, with the present unmodified code (version 0.5.0): shapes, events, features. This is encouraging because it means you can create SVG shapes and receive events. The bad news now: all the other apps are not working (yet).

How do I interpret these results ? It seems IE9 is a two headed beast, and these two heads do not talk to each other at all. Either you choose the new IE9 mode, by putting the HTML5 doctype header in your document; or you choose the compatibility mode.

In IE9 mode, you must do everything by the standards (CSS layout, HTML5, W3C DOM APIs). If you deviate a tiny bit or try to use the old IE way, it won’t work, contrary to other browsers which know how to handle legacy and degrade more gracefully.

In compatibility mode, you basically have that outdated and full of quirks and bugs browser, which knows nothing of the new features but has good compatibility with legacy MS apps.

So you cannot have your cake and eat it too. Currently this is not very good for the combination of GWT and lib-gwt-svg. GWT has not evolved yet, its widget library is designed for the old version of the browser, so GWT apps probably will work better in compatibility mode. However lib-gwt-svg is clearly designed to work in IE9 mode, because it requires SVG, only available in this mode. This is why (I think) so few apps currently work: as soon as you start doing GWT UI in IE9 mode, it breaks. Probably the GWT team will have to address IE9 in IE9 mode as a completely new user agent, which is a lot of work. There are chances most apps will run unmodified once this done. To encourage google engineers, you can vote for issue 5125 to show your interest in the topic (click on the star next to the issue number).

More on CSS layout of SVG applications

admin — Wed, 10 Nov 2010 18:25:30 +0000

lib-gwt-svg-samples and lib-gwt-svg-chess have been fully ported to GWT2.1 and I am releasing today these new versions. These applications were already working with GWT2.1 but they were still using deprecated classes for UI layout. They have been transposed to a 100% CSS-based, strict-mode layout, so the resizing should be faster and the layout more consistent accross browsers (see my previous post on CSS layout for SVG elements in GWT applications). I have also pushed the code of lib-gwt-svg-samples to the maven central repository.

lib-gwt-svg 0.5 is available

admin — Sat, 30 Oct 2010 15:29:38 +0000

I am releasing today version 0.5 of lib-gwt-svg. The new version contains many new features.

The API has been migrated to include the lastest update from the SVG specification (SVG 1.1 second edition, W3C Working Draft 22 June 2010). See the release notes for details of the API changes.
Documentation captured from the SVG specification has been translated to javadoc and injected everywhere in the API. All the non-W3C APIs have been documented. Many links pointing to the W3C spec have been added also.
Exceptions declared in the specification have been mapped to java exceptions and the corresponding throws clauses have been added to the specification. The article on lib-gwt-svg design has been updated to reflect the design decisions behind these changes.
Many new helper methods have been introduced (xpath utilities, DOM-level 2 related methods, graphical methods).
An SVG validator has been integrated. It is enabled by default and checks at build-time all the SVG passed as SVGResource, ExternalSVGResource and inlined in UiBinder templates. The SVG validator is based on the experimental XML schema provided at W3C with custom fixes and improvements. It is possible to disable validation with the proper annotation or UiBinder attribute.
The library is now based on the GWT 2.1 final release.

October 2010 svg news

admin — Sun, 03 Oct 2010 14:59:29 +0000

Many exciting news to begin this month of October !

First a new release of lib-gwt-svg (version 0.4.9). It fixes a few bugs, adds more classes to provide a a more complete DOM level 2 access, adds a few utility methods. It is based on GWT 2.1 M1. If you need it for other levels, please contact me. More on this topic here.

Second, I am really happy to announce the release of my first version of vectomatic2, an online svg viewer. Vectomatic2 is the reason I started lib-gwt-svg in the first place, as I needed a GWT toolkit to manipulate SVG. I plan to make vectomatic2 evolve into an SVG editor, so expect new release in this direction in the coming weeks / months. Vectomatic2 works on all SVG enabled browsers with GWT support (this means: IE9 not yet, but this will come soon hopefully). More on this topic here.

Third, I am also releasing a new version of my SVG games. I redesign them completely to make them more modular, so that I can add new games more easily. I have also solved my resizing issue and come up with a good way to use SVG and CSS to make SVG UI resizable. The maze game is now available for Chrome 7 users (and it is super fast !). I have not been able to port the other games yet as Chrome 7 has still too many SVG bugs (problems with transforms, and use elements with transform). But it will come eventually. More on this topic here.

Vectomatic2 SVG viewer

admin — Tue, 28 Sep 2010 09:04:51 +0000

I am very excited to announce the release of my dearest open-source pet project: vectomatic2. It is a rewrite of my earlier vectomatic project along new lines: SVG technology (based on lib-gwt-svg) and GXT UI.

It has been tested on the following web browsers:

Browser	Version
Firefox	3.x or greater
Opera	9.x or greater
Chrome	6.x or greater
Safari	5.x

Currently the features are limited to those of a viewer:

You can open arbitrary SVG files. It is connected to the RSS feed of the great OpenClipart project so that you get a fresh supply of SVG to manipulate.
You can manage several documents at the same time (which will prove useful when the application will allow cut and paste between images).
You can easily scale are rotate the images (which will prove useful when you want to work on particular detail).

The plan is to make the application evolve from an SVG viewer to an SVG editor.

If you use an old browser and cannot use it yet, you can watch this video demonstrating the program:

SVG games rearchitecture

admin — Tue, 28 Sep 2010 08:55:44 +0000

I have done a major re-architecture of lib-gwt-svg-edu, my educational game project. You can see the results here.

The project had become too big to fit under the umbrella of a single maven project: it was slow to compile, the various games where tied to one another, and adding more games seemed problematic. So I bit the bullet and decided to re-architecture it. I split it into several independent project:

lib-gwt-svg-edu-commons: This is a library to group miscellaneous classes which are reused in the games.
lib-gwt-svg-edu-dots, lib-gwt-svg-edu-puzzle, lib-gwt-svg-edu-push, lib-gwt-svg-edu-maze: These are the game projects per se. They can be run independently or as deferred GWT modules integrated under a root portal GWT application
lib-gwt-svg-edu: A desktop oriented portal application

Here are the benefits of the new architecture:

It is much easier to add more games
You can work on just your game and focus on it without being bothered by the rest of the project. Notably this has enabled me to do some work on lib-gwt-svg-edu-maze and it now works beautifully on Chrome 7 too ! I hope I can port the other games soon, or at least file more Webkit bugs as I get better understanding of why they do not yet work on Webkit based browsers.
There is a potential to reuse the games in more environments. I plan to make plasmoid and Opera widget version of the games. I also would like to develop a new menu to target mobile devices.

On SVG, CSS and GWT

admin — Tue, 28 Sep 2010 07:38:44 +0000

My CSS-layout lightbulb has finally lit up !

One of the most serious problems I had been facing with my SVG apps is that the layout and sizing of SVG elements was never right. The interactions of the SVG width and height attributes, the CSS width and height properties, and the rest of the HTML elements baffled me. The behavior was erratic, never identical from one browser to the next, and I had resorted to extreme measures (add window resize handler to programmatically recompute the size of the various elements) to get a half-working and slow layout. Hopefully these days are behind me.

Here are the few rules I have been able to determine which really save the day:

Do not layout your applications the old way, using invisible HTML tables. This is EVIL and will especially not work if you put SVG elements into table cells. This means you can throw away most of GWT classic layout pannelry: be gone, all com.google.gwt.user.client.ui.ComplexPanel subclasses ! Use simple com.google.gwt.user.client.ui.FlowPanel or com.google.gwt.user.client.ui.AbsolutePanel with the proper CSS styling.
Forget quirks mode and go to CSS strict mode. This means that all you applications should use a doctype declaration. HTML 5 seems to be the one to use (this will prepare your app for IE9 compatibility):
Use CSS positionning attributes intensively: left, right, top, down, along with absolute positionning and percentages. This works beautifully and most importantly cross-browsers

To see all these rules in action, you can look at the new version of lib-gwt-svg-edu games. Resizing is much faster, the application can scale to any device size. It also really makes sense now to use SVG push buttons to control your app (instead of classic image-based buttons), as they will scale properly and be rendered at your device top-resolution