Growing Interest and Spreading Knowledge on SVG
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.
Starting with Sprites and Animation
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.
Steps for Making an Ant Build with Eclipse

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

XML to CSS with XSLT How-To
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.
Converting Simple XML to Lua Tables with XSLT

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
JSON and the Quest for the Javascript-friendly Feed
Johan and Jeff have started a discussion on the relative merits of JSON/JSONP. I think it's time I threw my two bits in. There are a couple compelling features of JSON as a format to Javascript coders (I count myself in here). Johan talks about getting around the same-origin policy. I understand the frustration, but I feel uncomfortable opening the door for someone else to execute whatever code they deem fit on my visitors' browsers. I know they're not supposed to, but the can. It's a lot of trust. It's true that Javascript executes in a sandbox, but the code in question doesn't have to be intentionally "bad" as Jeff implied. It could be accidentally bad code. Accidentally bad code happens a lot more often than intentionally bad code. It can be worse because it's Accidental. Accidentally bad code can excersise memory leaks or any other bugs in a browser. I'm not saying that I write better code than everyone else, just that I can debug more easily if it's all served from my site. Mixing code and data makes things tougher. Not that we haven't already gone pretty far down that road. After all, Javascript in a web page is executable code mixed in data. That said, JSON is clearly a simpler format to process on the client side for JS engines that are not inherently XML-aware. This is changing with support for XPath showing up in browsers, so JSON might be a shortcut for now. As a content-provider, it looks pretty simple to create a JSON feed from an existing XML feed, so I've got no issues with supporting it that way. Well not at first glance. Then again, the feed isn't guaranteed to be valid Javascript syntax though if I don't test every feed with a Javascript parser. If I'm doing that and the client also has to validate what I've sent them then suddenly we're both doing a lot more work. What's more, if users start throwing in references to their own scripts that the server producing the feed can't see, then how can the server possibly guarantee a valid feed? That's the problem with formats that look easy. Most of the time they end up needing some kind of patching later that starts quickly to look like a kludge. JSON's not the first place this has shown up, just the latest. I mean PHP has had plenty of growing pains and broken plenty of existing code in order to get more secure default behaviour in place. Things like register_globals and the ability to reference a variable without defining it first are places that PHP used the normal behaviour for a script, but that normal behaviour caused big security issues when the language was used to build huge applications. And don't even get me started on the nightmare of escaping script embedded in text embedded in XML embedded in PHP. Each of those started as an idea to make things simpler and more readable. When shorthand syntaxes like JSON crop up it indicates that developers feel that there's too much overhead in dealing with the predominent formats: Atom and RSS XML feeds. Someone could have come up with an equivalent PHP syntax. There's as much PHP code handling XML out there as there is Javascript handling XML. PHP has an eval() function analagous to Javascript. PHP supports associative arrays and objects. Why not feed my PHP script with PHP code? I don't know the answer for sure, but I'd guess that it has to do with the fact that PHP has an established method (well, many established methods) for handling XML. JSON just seems to be a request for data that's easier to parse. My answer? I guess I believe in proxying on my own server and getting the data ready for my clients in some Javascript that's easy to run.
Starting Point for a Puzzle Game Built with XSLT, SVG and Javascript
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.
O12X to ODF
Tim Bray upset Scoble a couple days back with a brief post questioning Microsoft's decision to go their own way with a proprietary XML format (he calls O12X for short) instead of the more established ODF. Scoble's defense of O12X sounds to me like a "not-invented-here" attitude toward ODF. I know Microsoft has a lot more riding on the decision of when to support ODF. The longer they wait, the more support can build for O12X and the more they can benefit from the incompatibility. If O12X outlasts ODF, then life is easy. If ODF sticks around and takes any noticeable market share, they'll just release an exporter that they've probably already built and tried out (either officially or just some coder's side-project). There's nothing really surprising or new here to me.
Apache’s not a Web Server
Funny I mentioned just yesterday not to confuse Apache Foundation with the high-profile Apache HTTP Server Project. I say it's funny because I started looking today at trying out Tomcat. Once I started surfing around the site, it occurred to me that I never had gotten to testing any of my SVG examples in Batik. Batik, if you haven't heard of it, is a toolkit for working with SVG in Java. So the funny part is that I kept skipping around the instructions trying to figure out what I would have to do in my httpd.conf to use this thing. While I'm sure there are lots of ways to use Batik on a server, and I still intend to, it works just fine with the JVM on any old home computer. After I grabbed Batik 1.6, all I did with it was a simple test with the rasterizer demo application to render and slice up an SVG image, but Batik ran like a champ. It can't crank out a PNG as fast as Adobe SVG Viewer can pop it up in a browser, but finally it's a simple way to produce a high-quality raster image from an SVG. I've used ImageMagick and the Gimp for this now and then but they don't handle SVG lighting filters at all. SVG on the web is great, but you have to wait for end users to adopt it. With Batik, I can use SVG as a tool in the development chain for any project where I see it fit. I see this in the same way as I see XML in general being applied. There are plenty of sites out there (mine included) using XML and XML-derived languages being used out there behind the scenes. It doesn't have to be delivered to the end user to be useful. If you want to see how well Batik does then have a look at these demos - delivered via Java Web Start.
The XPointer Registry
The XPointer Scheme Registry didn't sound like that big a deal to me when I first saw this notice. But I needed something to read while watching my kid at skating (no wifi in the arena :( ). I didn't know what I was looking at when I started reading the XPointer Framework Recommendation since I had no context other than the announcement. By the time I was done, this is what I guessed.
Syndicate content