SVG Authoring Guidelines

SVG adoption has really kicked into overdrive with the inclusion of its capabilities in Firefox 1.5 when it was introduced last year.

Now that lots of people/companies are creating SVG web pages, a few common problems have surfaced.

One person has taken it upon himself to document what these problems are - and what to do instead, to make sure that SVG pages are enjoyable by the broadest audience possible.

It is a short document, and well worth taking 5 minutes to read - as well as bookmarking for future reference.

J. Watt, in SVG Authoring Guidelines, says:

There are a lot of mistakes in the SVG documents currently found on the Web. Because Adobe's SVG Viewer ignores many of these errors, the maintainers of these documents usually don't realise when they're doing something wrong. Unfortunately, the result is that far too often SVG on the Web doesn't work in Mozilla, Batik or one of the other SVG implementations. It is important that these problems are addressed as soon as possible to prevent them from propagating into authoring tools and the SVG documents that people will write in the future.

This document highlights some of the most common mistakes made in SVG content, and explains what SVG maintainers can do to fix them. The hope is that the SVG community will read this document, and that individual members of the community will do what they can to make sure that SVG on the Web is as portable as possible. Please spread the word. If you see others making any of the mistakes described here, please let them know so that they can correct them.

Speaking for myself, I have to say, Thanks, Jonathan!.

It is nice when someone with so much technical knowledge and skill as a writer shares something so important and useful with the community to which they belong.

Technorati tags: svg, authoring

Synchronized Multimedia Integration Language (SMIL 2.1)

Over seven months ago, back in December, the W3 approved a new version of the SMIL standard - version 2.1. Technically, it is not a standard in the eyes of the W3 - but a recommendation (Technical Recommendation).

That fact aside, it is a great way to portray compelling presentations with realtime aspects to them.

While the web was originally static text and graphics, combined with a way to navigate from one page to another - nothing about SMIL is really focussed on static presentations.

SMIL presentations are dynamic and dramatic. They move. They change. They animate.

SMIL documents are alive, and lively.

Whereas SVG has basic capabilities for animation, SMIL has very sophisticated capabilities. And now it and SVG can in some ways work together.

Synchronized Multimedia Integration Language (SMIL 2.1):

SMIL 2.1 has the following
design goals:

1. Define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL, an author can describe the temporal behaviour of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen.
2. Allow reusing of SMIL syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL components are used for integrating timing into XHTML [XHTML10] and into SVG [SVG].
3. Extend the functionalities contained in the SMIL 2.0 [SMIL20] into new or revised SMIL 2.1 modules.
4. Define new SMIL 2.1 Mobile Profiles incorporating features useful
   within the mobile industry.

The list above, which appears in the SMIL 2.1 spec itself, makes it pretty clear that SVG is very important to SMIL, as is fitting into the whole framework of XHTML-compatible document standards.

SMIL has been around quite a long time.

Always kind of impressive from a gee, wiz sort of standpoint - now it is getting some seriously really powerful capabilities thanks to synergy with other W3 media-document standards.

Not surprisingly, SVG is benefiting from advances made in yet another W3 recommendation.

Technorati tags: smil, svg, w3, standards, web, animation, graphics, presentations

You mean Cocoon does SVG too?

Surprisingly, not many people have heard of the Apache Cocoon server/framework/components. That is really too bad.

Things have really tilted at last during the past year or two into the the full bore use of XML in order to get user friendly products to market.

Run of the mill applications are easily created using run-of-the-mill techniques. That is what the 1990s were all about.

Recreating the 1970s style dumb terminal block mode user interfaces on a decades more advanced screen and keyboard setup added... images, styled fonts, and a mouse. That may sound like heresy, but it is true.

However, in the late 1990s - there was a slight course change. It was basically taking place at the W3. They noticed a lot of information was going into web pages, and sadly, a lot of it would never come out again.

The reasons were varied but one big problem is that web designers/developers/authors were using HTML more like a paint set than elements of a world wide information system.

Google noticed this, and cashed in big by providing a way to search these massively non-structured, come as you are, anything goes web pages. Yahoo got its start, even before Google came on the scene, as the first truly gigantic hand-maintained catalogs of web pages.

Fast forward to the middle of the first decade of the 21st century. We now have free tools on our desktop that do some pretty magical things, all thanks to XML, which is as easy for computers to understand - as web pages are for ordinary people to understand.

Last year, in late 2005, Firefox 1.5 was released. One of the things it introduced was built-in support for displaying SVG graphics. Until Firefox did it, no other major web browser had that SVG image displaying capability built right in.

However, Apache Cocoon, another free/opensource software program, has been providing very elegant SVG support on the web server side of the web for about half a decade.

Apache has a couple neat components in it that come directly into play when working with SVG.

There is an SVG-to-XML Serializer. It takes SVG information and publishes it in an XML format of SVG. Flexible from a software standpoint, but not too pretty to look at from a human standpoint.

There are some other SVG serializers that render into well known image file formats. People with legacy browsers that don't support SVG directly yet will be more interested in these, pro tem, than the SVG-to-XML serializer. Here are these other serializers:

• SVG-to-JPEG serializer
• SVG-to-TIFF serializer - Mac OS X really likes this format, and Group 3 FAX uses it as well
• SVG-to-PNG serializer - PNG offers fantastic compression compared to GIF and often JPEG too

Someone has already harnessed this XML-driven data management and display power that is built into Cocoon, courtesy of SVG, to produce an interactive data exploration tool. The tool lets the user graphically investigate various statistics about voting errors in the French 2002 election.

This same information would be very difficult to digest in dry tables, which is how we would all probably be looking at it if this was 1996 (or 1976 ).

However, it the 21st century now, so they used Coocoon to process the information and render it into interactive maps that presented the information as it related to the geography of France. A pretty clever idea, considering the relevancy of geography to voting in the first place.