Late Night PC

I've been working on rewriting my Wordpress SVG inlay plugin as a Drupal module. So far it works pretty well but I'm not ready to say it's secure or functional for most sites. The basic concept of the SVG inlay is that sometimes you just want to display an SVG image in a post or page. Not as a style element but as something that visitors want to look at which is relevant to the content. Like a chart, a graph, a network diagram, maybe even a little game.

The SVG Open is shaping up fast. The call for papers has been out there for a while now but if you're quick you can still present a paper or run a workshop but the deadline to submit for papers and courses is April 18 and that'll be here before you know it. The SVG Open is the conference for people doing SVG. The SVG Open has been running since at least 2002 and seems to get a little broader appeal every year it runs. Look at the broad areas to cover: client-side Javascript toolkits, map overlays like Google's, widgets in Opera, cell phones and other embedded applications, UI elements in Gnome and KDE, desktop tools like Inkscape. Those are just off the top of my head, that kind of a list just didn't exist 5 years ago - not for mainstream applications like these. SVG is growing in adoption and I don't see that slowing down anytime soon. I've been out of the scene for a while but things have really come a long way all of a sudden. There's some great support across the latest browsers - compare that half-green Firefox 3 to the qualified "about half of the tests passed that test features supported by Firefox" from a few years ago. There are solid, supported tools that make SVG creation accessible to anyone. Inkscape may only consider their release 0.46 less than a 1.0 but it's a real practical tool that's adding features in leaps and bounds. Want some graphics to work with? The Open Clip Art Library has piles of subjects covered. There are more and more compelling reasons to choose SVG every day. If you're someone who's been applying SVG already then share what you know and go present it at the Open.

Introducing Get SVG. I've been working on and off over the past few months on a site around SVG advocacy as well as helping users with SVG who may just be looking at SVG as a means to an end. I think that there are enough applications of SVG and implementations of SVG renderers out there now that there's a need for a site like this. Those of us that are really interested in SVG are playing with it and some people are interested enough to actually deliver applications to users. Since the users of these applications may or may not care what SVG is, they'll need a place to look for help when things don't go as they expect. That's one crowd. When applications support SVG as an input or output format, it's often just one in a list of exports. Adobe Illustrator is one example of this. Apparently some versions of Visio have it too. More and more applications will offer this option, especially as the libraries they're built on continue to make SVG export easier. Since the feature is only a minor one for that application, there's not necessarily a lot of information in their documentation about the internals of the SVG file produced. Advanced users come in to cases where they want to do things, sometimes odd things, with these exported SVG files. These advanced users make up a second crowd. Some users are working with Inkscape because it's a great free vector drawing tool. Other users benefit from the SVG capabilities in the Gimp or ImageMagick. They're not SVG developers, they're artists. They have questions, experiences and interests. These people are a third crowd. Finally there are the more obvious groups of people who develop in PHP, ASP, Java or Javascript and have language-specific questions about SVG or the popular SVG libraries that they're using. This crowd is definitely important too (and I count myself primarily here as well). I'm inviting all these crowds to come and get involved in the discussion at Get SVG. It's early yet, but the sooner you get there, the better seat you'll have.

I got a little furthur with the websprites demo I started earlier this month. I've decided to hold off on the XSLT source document for now since I find the development toolchain just gets too long for me at this stage. Maybe when I have more documents to generalize from I'll go back to using XSLT for the source. After all, isn't that what XSLT is for? Transforming many documents with the same semantics in a similar fashion? I found that I didn't have a thread to extend from. What I've done on this little sprite demo is just one document that I really don't have a concrete plan for right now. Really it's just a few documents. One HTML document, one SVG and a Javascript source file. So I went to work on building just the pieces as they're delivered to the browser. The DHTML document is similar to what I showed earlier, but with some more interaction. The SVG version provides the same visual result at a given resolution as the DHTML version, but through a slightly different mechanism. The two versions are similar enough that the same Javascript drives both with just a couple lines that are conditional on the file format.

You might've guessed from the names in the example I gave the other day, getting Ant to process XSLT2 with Saxon, that I'm doing some sprite animation stuff. I am. And so far my output is in DHTML. The whole development isn't perfect yet, but I've got a simple DHTML sprite that seems to work. If you're not familiar with the term, a sprite is an animated block. Every time I hear the word it reminds me of myCommodore 128. Sprites on that machine could be set up by poking colour values into the right spots in memory, basically drawing out a bitmap. Sprites are basically just little raster images that are animated by replacing frames quickly. After the little CSS mouseover example I threw in last week, I started thinking about how simple it would be to use the same technique to animate the background-offset value to create the illusion of animation.

I don't have a whole lot of time to test at the moment, but really want to see how the new Opera 9TP2 performs on SVG in Linux. Here's an overview of the features from Opera Labs. I just installed from the RPM over here. It's not relocatable (with the rpm - -prefix option), so I hope it doesn't mangle anything on FC4... The first things I looked at were SVG Basics and my blog stuff. My examples at SVG Basics don't show up in the page at first. My first guess is that it's because I simply used an embed on those pages, since I can browse directly to the SVG documents and they look fine so far. What's odd is that if I view the SVG image, then go back to the page containing the embed, then it shows up in context properly. I may have to file a bug report I guess. Text selection on a path isn't there, but the text seems to be rendered correctly at first glance. Decorative text looks nice, the stroke-linejoin example might have something funny with it. Image filters look nice (colour matrices, offsets, drop shadow). My simple game example kind of works. Jeff stats look nice and I saw the snow on his blog for a bit there. I wish I had the time to get deeper into this now, but I really have places to go and all that. I'll have to wait until I can get back to my Linux box to do more testing.

This one's for the casual game developers and the SVG folks I've been working off and on (okay, mostly off) on a simple puzzle game done in SVG and Javascript. I started on it almost a year ago and the idea was to just put up something simple as a guide to building SVG games. I got something that sort of worked pretty easily, but each time I added a feature it seemed like I had to rewrite the whole game. I guess that's just part of developing in a green field. One of the issues that bothered me most throughout the work I did was that I was transforming level files from a generic XML to SVG in the browser. I knew that every browser that downloads the level would perform the exact same transformations and every user would have to wait a few seconds while it happened. I also had to deal with the rather hairy Javascript code that handled those transformations and debug it every time it broke on one of the platforms I'm trying to support. Not every browser has a debugger as accessible as Venkman (and at the time I don't think there was a Venkman version for Deer Park). I'd rewrite the code, get a little more capability in it and tweak it for a day or two, then shelf it again until Jeff or Candace bugged me again to stop talking about it and get something done. Okay, so I finally did another rewrite on it a month or so ago that fixes the issue that I'd avoided for so long. See, I'd wanted to keep it in just Javascript and SVG since I thought that made things simpler. There's no build step that way and the design of the game is more obvious. Scripting languages don't generally need the kind of development pipeline that compiled languages do. In C or C++ the source code has to be built before results can be seen. In Javascript or HTML, the source is the executable. When XML is used to store information though, there's always some kind of interpretation that happens to display it. That can happen right when it's accessed (like viewing an SVG or XHTML document) or there can be interpretation first that creates another document that's actually viewed. The latter transformation can be done with XSLT.

I always thought fractals were a great source of eye candy. I've been meaning to write something that plots a fractal using SVG for some time now, but I actually got started from this old post on VML fractals. I rewrote the code at first to use SVG, then I started reworking and optimizing to get something that runs at least decently in Firefox.

Jeff just put up some web stats made pretty by graphs done with SVG. He's also got a way of embedding SVG into an HTML page that shows up in most browsers. For many browsers an object element is enough but Internet Explorer with Adobe SVG Viewer 3 requires an embed tag to work properly. I think that's the gist of it. Jeff's got a good snippet of code to handle this, but it's kind of ugly and not convenient to use in a blog post.

He showed me a sample page with the graph embedded (not done in Wordpress) and it was too cool to let it go. I've been fooling with some plugins for Wordpress (1.5.2 I think) lately, so I though I might have a fix for his posting problem. What I came up with is a plugin that lets the author use a special tag, <svginlay />, to refer to an external SVG file. When the post is displayed, the plugin uses a filter to replace the <svginlay /> tag with some HTML that will render the SVG image properly on a lot of platforms. Everything up to here happens on the server side in PHP. Note that the post is stored in the database with the svginlay tag in it. This is good because it can be picked out and changed later if there's a 'better' way to portably embed SVG. The actual HTML that's inserted into the page has some browser and feature detection stuff that includes Javascript, an embed and an object. That part will do what's needed on the client side (at least for current Firefox, IE and Opera browsers).

If you want to see it, click here to get the source.

I start out talking about how SVG can one day be abused the way html is today. Abused in the sense that new technology is first adopted by people who want it to work, later it's used just as a means to an end. That end sometimes is achieved at the cost of loss of the intended use of a service. In short, new technology means new kinds of spam. How do we allow user-created SVG to be published in communities like forums, wikis, blog comments and anwhere else - but without risking user security or letting in new kinds of junk? I end up with an idea for the Javascript problem that I called bbscript. (Why is it that podcasting makes me get ideas?) I bet that's already used. The inspiration here was just the idea that we should be careful not to repeat all the problems built in to the Internet technology we're building on top of. Anyhow, have a listen and if you're inspired then go build something. Links to stuff I mentioned:

• The top link on a Google search for VBS refers to a VBScript worm
• Jeff's Crap Wave
• BBCode