No, I am better than that! » batik

Generating scalable, stretchy, and smart graphics with ColdFusion – Part 4

Rick Osborne — Thu, 31 Jan 2008 13:00:12 +0000

In yesterday’s post, we built a renderer for our SVG files. That’s all fine and good, but there’s not much point to having a renderer for static files. What we really want to do is render dynamic files, where the data inside the file is manipulated somehow by ColdFusion. Of course, this is a pretty nebulous request, as your data manipulation needs are only limited by your imagination. But for today, I’ll be going through a few things that I’ve needed to do.

To do all of this, we’re going to build what I’ve called an “SVGmunger”. At its heart, it’s straightforward:

Load an SVG template file.
Iterate through a series of modifications to the XML document.
Save your changes to a new file.

My SVGmunger has gotten more complex as I’ve used it in more applications, but there are a few core functions: load, saveAs, setText, setAttribute.

The load function is exactly what you would expect it to be, as is the saveAs function:

You’ll notice that there’s a little extra magic in the saveAs function having to do with character encoding. CF and Batik don’t quite see eye-to-eye on XML character encoding, especially not when you start adding international characters into the mix. Beyond that, there’s nothing outrageous, right?

Now that we can load and save our SVG file, we need to be able to make changes to it, which is where our setText and setAttribute functions come in handy. The first, setText, replaces the text part of an element (between the tags), while the second, setAttribute, replaces the content of a single attribute. If you think about it, these are the two primary operations you’ll be needing. If you want to change some of the text in a graphic, such as to put in a person’s name, you’ll be changing an element’s text. If you want to modify the look of a graphic, such as to change a color or transform a layer, you’ll be changing an element’s attributes.

Sure, you could do both of those by hand in code, but why?

First, we use XmlSearch to pick out the element we’re looking for. Second, we do a bit of cleanup on the NewText argument—setting it to a single space means that the XML handler won’t collapse the tag, which we may not want to happen. (You are welcome to take out that line if it doesn’t suit your needs.) I’ve managed, via dumb copy-n-paste, to have more than one element with the same ID, so I use a loop to get all of them instead of just a single cfset statement. Within the loop we set the new text, then we clear out any child elements. Again, if you don’t need to clear out any child elements then you can eliminate that line.

As you can imagine, setAttribute is the same thing:

The only thing different from setText is what we do in the loop—this time we set the attribute to the new value, and don’t have to worry about mucking around with child elements.

You’ve probably noticed that both of my functions depend on knowing the ID of the element you want to modify. You could, of course, write functions that operate on XPath instructions instead of IDs. But, really, why not just take a moment and add some IDs to the SVG file? It’ll certainly make your code, and the SVG file, easier to read.

Congratulations, you can now muck about in your SVG internals without having to write a bunch of nasty code:

Once you have these basics, you’ll quickly find that you want more. I’ve got a function that takes a query full of modifications and iterates through it, making each modification in turn. This is great for the progress graphs on NoWrists.com, as I can make a bunch of extensive changes to a template without having to write much code. You might prefer a function that takes a list or array or another XML document or whatever.

As you really start getting into it, you might find yourself in a position when you want to do more than just modifying a template. In my running graphs, for example, I have a series of mile markers. Logically, I should have just one “Marker” element/layer in my SVG template, then I can clone that element/layer any number of times to create as many markers as I need. However, I know that I’m not going to run an infinite number of miles, so it was just as easy for me to have 20 markers in my template, then only show and move the ones I need. It’s cheating, sure, I admit it. If you want to make more sophisticated functions for your SVGmunger, you go right ahead.

In the next post I’ll go through and make some eye-candy to show off some of the things we can now do with our new SVGmunger and SVGrenderer components.

Generating scalable, stretchy, and smart graphics with ColdFusion – Part 2

Rick Osborne — Tue, 29 Jan 2008 13:00:01 +0000

This post will be a really basic intro to SVG graphics—how they are structured, and how you can generate and manipulate them, primarily with ColdFusion. But you don’t have to wade through my prose, you are welcome to skip straight to the SVG Spec by W3.

Let’s start with a really basic SVG image. The image below is a PNG rendered from the SVG, but if you click through you can see the source file. Depending on your browser’s support for SVG (almost every browser other then IE supports SVG natively), you might see the raw XML or a rendering of the graphic.

SVG source files are XML before they get rendered into GIF, JPEG, or PNG formats. The source for this graphic is straightforward:

At the top of the file you can see typical XML stuff: an XML declaration, then a root node. The root node references two namespaces: one for the SVG format (duh), and the other for links within the file. The latter allows for things like gradients and stock text, which are accomplished by referencing definitions in other parts of the document. Beyond that, there’s a version corresponding to the version of the SVG spec, and basic height and width attributes. No big deal so far, right?

The defs section defines stock things like gradients. Gradients come in two parts: the first gradient defines the colors, while a second gradient references the first and maps those colors onto the canvas with specific coordinates. This way, you can use the same gradient in different places without having to redefine the colors. I’ve done this here, where #Tropical defines the orange and red colors, then #TropicalGrad and #StarGrad place those colors on different parts of the canvas.

The rest of the file is just drawing instructions. As you can guess, the rect element defines a rectangle. You can also see that SVG uses CSS for styling elements. Styles can be broken out into XML attributes, such as fill="#000000", if you like.

The g element defines a group, or a layer. Just like container elements in HTML, group elements are good for holding styles that the inner elements can use.

Text is … tricky. The v1.0 and v1.2 SVG specs handle text slightly differently, depending on if the text is a single line or multiple lines. Wrapping text blocks were not around until the v1.2 specs, and use a different set of elements: flowText, flowDiv, flowPara, and flowRoot. The v1.0 element is much simpler: text. On the one hand it’s much less flexible, but on the other hand support for it is much more uniform in various viewers and web browsers and renderers. I’ll have an entire post about handling text in SVG.

Drawable things are handled with the path element. Remember the old LOGO language with the turtle? Same thing. The d attribute handles the drawing instructions, most of which are very easy to remember.

The use element is similar to a #include or cfinclude, except that you will generally use it to clone an element from the same document. In this example, we clone the layer/group containing the text and star, then use a series of transform commands on it to pull the thing down, flip it, but not reverse it. Sorry.

The last rect is cheating a bit—instead of masking out the cloned content, I put an alpha gradient on top of it that starts transparent and fades to opaque. Masking is a little trickier, but not all that much, and it really comes in handy when you’re doing 32-bit alpha PNG files.

So there you have it, the basics of SVG: structure, basic shapes, text, groups, and transforms. There’s plenty more fine detail, but those are the broad strokes.

As a thought exercise, how much would we have to change if we wanted to put the graphic on a white background? Or a blue background?

Not much, actually:

The #Fade gradient has black stops.
The first rect has a black fill.

How could we modify it with ColdFusion? Presumably, we’d load the file as an XML document. Finding the specific places to modify should be as simple as using a couple of XPath queries. Something like “id('Fade')/stop” would work, and you could add id elements to the stops if you wanted to. Finding the first rect would be similar, and again easier if an id was added.

I’m sure you can see where I’m going with this—generating and modifying SVG with ColdFusion is wicked easy. In my next post, we’ll build an SVG renderer using Batik and ColdFusion so we can get some actual image files.

Generating scalable, stretchy, and smart graphics with ColdFusion – Part 1

Rick Osborne — Mon, 28 Jan 2008 13:00:32 +0000

This is the first part in a series of posts about an alternate method of generating graphics with ColdFusion. By alternate, I mean not based on cfimage. Since they are based on the Apache Batik Java library, you can do everything I’m going to show you on any Java-based version of ColdFusion. (I’d wager that you could probably do everything on versions of CF going even further back.)

First, the obigatory eye-candy to convince you that I’m not a crackpot:

My original post in Fall 2006 about image manipulation without CF8
Another post, 2 days later, with more graphics
And, of course, the graphs I make for my runs are all done via SVG:

Why would you want to generate images with SVG instead of the more traditional way — with cfimage or a similar raster-canvas-based approach?

Existing vector tools, such as Inkscape and Adobe Illustrator, can help you get a base template graphic up and going significantly faster than generating one through code. The exported SVG file can then be tweaked by hand as needed.
Similarly, you can have a graphic artist, someone who is paid to come up with pretty and swooshy things, do almost all of the work. In the best case, a programmer might have only a few minutes worth of work to do.
Dynamically-sized, stretchy, and “smart” images can be done with an absolute minimum of work and manual coding of complex layout logic. Almost all of the heavy lifting, like transformation math, is done for you.
Translating from a Flash file, or to a Flash file, is going to be significantly easier than with the traditional approach.
SVG images can do everything raster-canvas images can do, and much, much more.

But, of course, I’m going to try to be fair. There are a few down-sides to using SVG with ColdFusion:

Complex graphics can be server-intensive to render. I’d bet that an equivalent raster image would only render slightly faster in most cases, but an unoptimized SVG can certainly chew up the processor. I’ve personally run a graphics service on nowrists.com that has handled dozens of image requests per second on a 1GHz machine, so it’s not as hopeless as some might think.
Memory requirements are almost certainly going to be larger than raster equivalents.
If you want to really break out of the box and start doing advanced stuff, you need to be very comfortable with geometry. I think doing such things by hand with a raster canvas would be even harder to do than with SVG, but it’s still not for the faint of heart.

Having said all of that, what will you need to do this wonderful, magical stuff that I’m talking about here?

Exactly one thing: a Java version of ColdFusion. The default install will work for most things—you won’t run into problems until you need Unicode characters in your graphics. Even then, the fix is a 5-minute one. I’ll have a post on how to upgrade the default version of Batik later on in the series.

I would also recommend, but it is certainly not required, that you get familiar with a vector graphics editing program, such as Inkscape or Illustrator. The next post will introduce SVG and won’t use an editor at all, but eventually you’re going to want the rapid-development that an editor provides. I’m going to use Inkscape in all of my examples and screenshots throughout this series, but if you’ve got the the money and time for Illustrator, I don’t imagine you’ll have too hard of a time translating.

That’s it for now. I estimate there will be a total of 6 to 10 posts in this series, and that it’ll take me about 2 weeks to get through.