I've got a little project I'm working on where I've got an XSLT file that produces an SVG image that I subsequently want to rasterize with Batik. There's also a couple other resources that get built along with that. I've used Batik before for this task and I was impressed. The thing is, I had some long command line I'd set up to use it. While I like the fact that I can just type in what I want to do in the case of a one-off project, it bothers me when I have to go back and re-learn how to use a tool because I don't remember all the parameters that I used.

A build tool is a great way to parameterize what you're doing and keep track of the steps you followed. A build tool can be part of your IDE, it can be a traditional tool like the venerable make, or it can just be a batch file. I've tried all these routes in the past and each has pros and cons. Make is a great tool because it can do so much and is well-suited to the kinds of work that it automates. The makefile also serves as an artifact that details how a build happens for a given target in a given project. Of course the syntax of a makefile can be cryptic for advanced cases and the whitespace issues can be tricky even in simple cases. I was told by an old Unix hack once that there was only ever one makefile - every other one was copied off of that one.

So some clever wag came up with the Ant build tool. It's cross-platform and doesn't have some of the quirks that make does. I'm sure it has it's own, but I haven't seen them yet so I can be optimistic.

Since I'm developing this particular project in Eclipse and Eclipse comes with Apache Ant, I thought this would be a great opportunity to try it out. I want to see how hard it will be to have Ant handle my simple project needs and

I set out today to write about converting a simplistic XML document into a simple CSS stylesheet. The specific example I chose to work with creates code for CSS-rollover buttons. The first part I deal with is how to create such a rollover manually. The second part is about generating CSS like this using XSLT and a homemade XML language.

Making the Graphics with the Gimp

I started with the Gimp. First I used the Simple Beveled Button Script to produce a button. After that I made another, but set the upper right colour to be a little brighter. Next I made the same button again, but this time I checked off the "pressed" checkbox. So now I've got three images in the Gimp that represent the three states of the button I want to put on a web page. The first is the default state, the second is used when the mouse is over the button and the third is used when the button is clicked. There's a popular method of making the button change between these states very smoothly using just CSS. Basically you pack all three images into a single image file. This single packed file is just an ordinary image (gif, jpeg or png) that has all three states of the button one next to the other. The picture is set as the background image for some otherwise transparent box. Then the background-offset CSS property is used to adjust the position of the background so that the different parts of the image are visible when the button is in each of the three states I mentioned. Oh, and the three states are distinguished with the help of the CSS pseudo-classes hover and active.

• Rob's blog
• 5 comments
• Read more
• Buy Rob a coffee

An idea came up recently in a thread on Gamedev.net about scripting where someone made the statement that Lua tables would be more convenient for storing data than would XML. I don't have any idea as to the veracity of that statement, but I do know two things:

1. There are more tools to work with XML than there are Lua
2. Parsing XML in Lua sounds dumb

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.

Update: In the examples I discuss below, the tspan should be inside the textPath, not the other way around. Source files and the formatted versions are updated as of 8/31. Thanks to Holger for pointing this out.

I want to make another simple example of XSLT and SVG today. So I'm going to do another XML document and transformation. The mechanism is similar to my last example, but I'm not using any of the same SVG. Today, instead, I'm going to show an example with a textPath for making some wavy prose.

It also happens that the Mozilla team just landed support for textPath last night for Firefox trunk builds. I developed today's example in Internet Explorer with Adobe SVG Viewer 6 preview, but I'll be testing later with Firefox. If you want to use the latest trunk build of Firefox for testing, get it here.

I was thinking over the SVG lighting examples that I presented over the weekend and I wanted a clean way to produce something more complex that utilizes the lighting effect that I came up with. Examples are easiest to learn from when the information can be presented in small chunks. I think that logic carries through to code analysis. If there's no good reason to make big long functions then I stick to what fits on my screen. That's very developer-centric of me, but I am a developer.

So the way that I know to keep things small when it comes to XML is XSLT. That might sound backwards since XSLT and XML can be very verbose, but what I mean is that units can be independently analyzed. Large and complicated functionality can be elegantly composed from many small blocks. Chunks of code that I've produced with XSLT tend to be quite digestable - so far.

I've decided that I have to start using XML on PHP 5, so I thought I'd take some notes on my quick skim of the support available. Read on to get an idea of how the different PHP extensions relate to each other.

One important detail I didn't mention in yesterday's post on converting between XML and HTML was the "disable-output-escaping" attribute. Using disable-output-escaping="yes" causes the result of the transform to keep "< " and "&" in the resulting document. Otherwise, they get turned in to &lt; and &amp;. You may have found that HTML tags, <, and & all get stripped from your XML every time you do a transform.

I've used server-side packages for websites and I've done hand-coded HTML. Hand-coding is a simple way to start a site that won't have too many pages, but what do you do as the site grows? Suppose you've got a menu along one side that lists all your pages. Every time you add a page, all the pages have to have that menu updated. The usual solution to this is with a handy bit of Javascript for nice dynamic menus (that may or may not pop up an error message with every mouseover) or some PHP to fill in the details as needed. These are both valid. I want a template for the common parts of the page and a source document for the content that populates each unique output page (that is, the static web page that the end user can read). Since I've been monkeying with XSLT lately, I decided to try reworking my pages into an XML based format. My needs are pretty straightforward, so I thought this would be a good learning experience.

In pursuit of useful applications of SVG, I've become interested in using XSL transforms to turn data stored as XML into an SVG representation. I found a good starting article at A List Apart and it pointed to a great reference by Paul Grosso and Norman Walsh. These might be dated now, but I found them helpful starting points.

On to my example. We're going to need some data. I had a look at StatsCan and found a report on population by sex and age group. I would have liked to get some more complete raw data, but it appears to cost a few bucks, so I'll make do. I believe there are ways to scrape the data out of the table with just XSLT, but since this is a learning experience for me, I decided to skip that step by just pulling the numbers out by hand and creating an XML file with a text editor.
The results of my effort look a little like this:

The root node is called "populationbyageandsex" and each record (or row of data) is kept in a "recordbyagegroup". Between the open and close tags for "recordbyagegroup" are the fields for that record. Each field has a unique name and the content (between the open and close tags) of the element is the value of the field. The format is something I just made up for this example, XML is nice that way.

The next step was to write the XSL transformations that would understand the data well enough to create a chart in SVG.