1. Joe User knows nothing about the SVG format other than it’s an image format.
2. Starts a new document in Inkscape
3. Imports a raster image (PNG) from the hard drive
4. Saves image as SVG
5. Uploads the SVG file to a clip art website
6. Is baffled why the image displays fine on his computer in the browser but is blank for everyone else

Yes this could really happen. So how do we fix it?

• Warn during Import stage of local references?
• Warn during Save stage of local references?
• Embed raster as a data: url in the SVG source (breaking link with local file)?

Some highlights from the release notes:

• 3D Box Tool
• Implementation of many filters to generate cool Photoshop-like effects
• Import/Export of a variety of useful formats (PDF, XAML)

Last night when I toyed with it to create my Lost clip-art, I came up with the following two suggestions:

1. Make the Colors Panel Easier to Find.

Honestly, it took me awhile to figure this out. This used to be the “Stroke/Fill” dialog, I think. The icon looks like a paintbrush. It’s next to the big ‘T’ on the Commands toolbar. Honestly, I think people coming from other graphics program will think of this as a “Colors Dialog” and not a “Stroke/Fill” dialog – so come up with a better icon, one that reflects colors. The tooltip needs reworking too: “Edit objects’ color, gradients, stroke width, arrowheads, dash patterns”.

2. Create a Clip-Art Mode of Exporting

In this mode, Inkscape should:

• Remove all elements and attributes not in the SVG and XLink namespaces
• Remove unused id attributes
• Vacuum defs automatically
• Remove width/height attributes on the <svg> element and replace with a viewBox attribute. Removing the intrinsic size will allow the image to scale to the browser window when viewing standalone.
• Remove the style attribute and replace it with several equivalent attributes (style=”fill:#939393;” would become fill=”#939393″)
• Remove unnecessary/redundant attributes (“stop-opacity:1″, for instance). In particular, if there is no stroke on a path, remove all stroke-related attributes.
• Collapse <g> elements as necessary, properly adjusting transforms

In my experience, this roughly reduces the SVG to about 1/3 of the original size. Compressing afterwards gets it even smaller (by at least half). For instance, my Lost logo is only about 700 bytes! What raster graphic format could display such high quality at full-screen at seven hundred bytes? Looks most impressive with Opera or Firefox 3 because there is a blur filter in place.

All in all, I’m pleased where Inkscape is heading – it’s really becoming a world-class graphics editor. If they could just make options for their SVG output quality (I know that you can save as Raw SVG and you can manually vacuum defs, but I think the above type of steps are necessary).

Furthermore, it’s best to pick bugs (at least initially) that don’t require full-scale immersions into software architectures to figure out the root of the problem. This wouldwill likely change ifas more time is spent working with such projects.

I just spent a half hour or so fixing a couple minor errors in the Basic tutorial in Inkscape. I had some back-and-forth conversations with MenTaLguY and Bryce on IRC and mailing lists earlier in the week where I learned that the tutorials, while deployed as SVG, are actually stored as DocBook format in the SVN repository. So here’s how I did things using my OpenSUSE 10.2 box.

A Caveat

But first, a caveat: I have yet to successfully delve in the code of Inkscape using OpenSUSE 10.2. I was able to get the latest source, I ensured I have all the libraries installed (as per YaST), and I was able to successfully make and install the trunk source. But upon running the trunk binary, it crashes. At this time, I haven’t been able to learn how to debug this sufficiently (my gdb experience is very minimal). So for now, I’m stuck doing some doc updates until I can spend more time on this and figure out which library dependency (presumably) is causing the problem. So far, that’s my biggest contention with the Inkscape development project – too many dependencies on libraries.

As always, if someone has a clue how to help me out of this pickle, please comment or send me an email. And yes, I’ve been to this page.

Check Out the Inkscape Documentation

First, make sure you check out the latest Inkscape documentation project trunk node. Note that this is a different folder than the Inkscape application project as described here.

For this step, you will need to have Subversion installed. The easiest way to do this is through Yast > Software Management.

Next, create a folder for the Inkscape Documentation project and from that folder, execute the following command:

Get The Right Version Of Saxon

The latest version of the Saxon XSLT and XQuery Processor is 8.9 (available through YaST), but for some reason Inkscape Documentation requires Saxon 6.5.3.

• Go to http://saxon.sourceforge.net/#F6.5.3 and download the Saxon 6.5.3 zip file.
• Unzip the file somewhere. Find the files saxon.jar and saxon-jdom.jar in the top level of this zip.
• Copy these files to /usr/share/java/ but make sure you rename them so they don’t overwrite any existing Saxon jar files. This will require you to be root:
  # cp saxon.jar /usr/share/java/saxon-6.5.3.jar
  # cp saxon-jdom.jar /usr/share/java/saxon-6.5.3-jdom.jar

Install Inkscape

If you don’t have a working copy of Inkscape installed, then go to YaST > Software Management, find Inkscape and install it. From the command-line you can find out where the inkscape binary is installed by typing:

Mine was installed at /opt/gnome/bin/inkscape.

Build DocBook into SVG

Now test out building the DocBook XML files files into SVG:

• Go to the top-level of the Inkscape Documentation Project repository that you checked out. This is the folder with all the make-svg, make-html scripts in it.
• Type the following command:
  ./make-svg basic /usr/share/java/saxon-6.5.3.jar /opt/gnome/bin/inkscape

  NOTE: Substitute the location of the Inkscape binary for your own, if it differs

This should create the basic/tutorial-basic.svg file.

Fix A Bug In The Tutorials

(Exercise left to reader. Go look at basic/tutorial-basic.xml to get familiar with the DocBook format. Find an easy bug on the Bug Tracker)

Submit Your Patch

Once you’ve made your updates, built the SVG, and verified that it looks good, you can make a patch and submit it to the Patch Tracker:

• Make a patch file (for this example, let’s assume you’ve updated basic/tutorial-basic.xml):
  $ svn diff basic/tutorial-basic.xml > /tmp/my-patch-file.txt
• Upload patch (/tmp/my-patch-file.txt) to the Inkscape Patch Tracker
• Inform the inkscape-devel mailing list

The cartoons themselves are very basic with no audio or true storyline, but they serve as examples for how the technique can be accomplished. One might easily extend these concepts to the web browser to provide more true-to-form cartoons (i.e. longer in length), but the key is getting good tool support for this. I’d like to see Inkscape supporting animations some time in the future, since animations are such a big part of SVG overall (and Inkscape seeks to be a SVG drawing program). At present, Inkscape is only for static images, though it is vastly improved in its latest version (released earlier this week).

Flash cartoons have been around for a awhile on the web and also serve as a viable means to stream cartoons out to mobile devices. Of course Flash is a proprietary standard, but it is much more mature.

Incidentally, the animations will not work in Firefox or Opera native implementations (Firefox does not support declarative animations. I haven’t debugged why Opera is having a problem). The TinyLine links in the above article use a Java applet to render the SVG but I’ve found that it is FAR too slow. If you’re using IE+ASV you can view the “surprisep” cartoon as it is meant to be seen at http://www.tinyline.com/svgt/samples/samples/svg/surprisep.svgz (will not work in Firefox or Opera without the Adobe plugin).

SVG 1.1 has a few particularities that make cartoons of any reasonable length problematic, most notably a lack of support for streaming media. Without the ability to stream the media to a device, the entire cartoon needs to be downloaded first before viewing can begin. However, it seems that SVGT 1.2 addresses the streaming issue, so hopefully the W3C can fix the remaining problems with SVGT 1.2 in the VERY near future and get it out there. Another notable exception is that without support for audio in SVG 1.1, you need another way to play and sync the audio track (or go silent like the above example). SVG 1.2 contains the ability to embed media (audio or video).

In terms of SVG on mobile devices, Europe seems to be taking the lead because SVG was chosen by the 3GPP as the defacto vector graphics format that must be supported. From this article it appears that “SVG Tiny 1.1 is required and SVG Basic 1.1 is optional”. Thus, we’re seeing a large number of phones (50 at last count) that now support SVGT 1.1. I’m not sure what the 3GPP2 are doing for North America and Asia, but I would hope they follow 3GPP’s lead.

Since 2005 seems to be the year that SVG starts to break out of its niche market in the desktop, it will be interesting to read some of the papers coming out of the SVG Open for 2005. If the SVG Open 2006 ends up in Victoria, BC as Kurt Cagle wants, I just may try to attend next year…