Programming Web Graphics with Perl & GNU Software

About a year and a half ago, I started investing on-line. The first thing I did was research the stocks I found most interesting. Yahoo's stock section is quite good—many important-looking numbers and graphs. The graphs took me by surprise—I hadn't, at the time, thought about on-the-fly images. Much of the data used for the graphs is fairly static (one-, three- and five-year reports, for example), but it makes no sense to keep these graphs around permanently. It would be an awful waste of disk space, and the data might change unexpectedly.

I am now far more familiar with image development in general, but until recently I was still fairly unclear on how dynamic graphics were built for the Web. I was, that is, until Linux Journal sent me a copy of Shawn Wallace's Programming Web Graphics with Perl and GNU Software. Although most of the graphs seen on the Web these days use in-house developed tools, many of them started out using the same tools described by Shawn, such as ImageMagick and the GD library.

As the name implies, Shawn's text focuses on writing tools using Perl. Almost all of the tools he talks about in detail have a Perl module, making it easy to integrate them into your scripts. Other tools work from the command line, so calling them from Perl is still fairly easy.

The text opens with some basic network graphic issues and a comparison of the most popular (web-supported) graphic file formats. The comparisons are quite good, providing information on header formats and some pointers on when and where these formats are best used. One interesting bit was on JPEG (Joint Photographic Experts Group). Apparently, the compression techniques in JPEG work well for the human eye's perception of color, but tend to distort text much more than GIF (Graphic Interchange Format). I didn't know that before reading this, and now understand that screenshots of dialog windows are probably better saved as GIFs. The trade-off, of course, is in file size. No format is perfect.

A couple of good and bad things can be said about the book. First, it sticks to well-known and published standards—in other words, it sticks to HTML 3.2. That is a good thing, but unfortunately it doesn't talk about HTML 4.0; for example, there is no discussion of style sheets. It also doesn't give much space to Netscape or Internet Explorer extensions. Deny it if you want, but either of these two browsers is the likely tool of choice for the majority of users. At a minimum, a table showing some of the differences or browser-specific extensions would have been useful.

Back on the good side, Shawn does an excellent job of introducing and defining APIs (Application Programming Interfaces). Throughout the book, he first discusses a graphic library interface, its API, and then follows with meaningful examples. Well, most are meaningful. That biorhythm example in Chapter 6 seemed just a little too Austin Powers for my taste. I lived in the 60's, and truly hate going back there.

Most chapters also include in-depth function references. This is highly useful information and somewhat unexpected, considering that each chapter starts with some straight, non-technical talk about what to do with these libraries. Again, Shawn goes the extra mile to provide the most useful technical information.

Two very good chapters are Chapter 5, “Industrial Strength Graphics Scripting with PerlMagic” and Chapter 7, “Web Graphics with the GIMP” (GNU Image Manipulation Program). The former is extremely useful, even if you're not doing web graphics specifically. It includes a very extensive description of the PerlMagic interface to ImageMagic.

The GIMP chapter is too sparse for experts and too technical for new users. However, it does provide information on the various animation options, much of which I didn't know. The section on Perl-Fu is good, but Perl-Fu requires Perl 5.005, which most Red Hat 5.2 users don't have. (SuSE, Debian and other distributions may have this—you need to run Perl -V to find out.) I find it a bit annoying that so many application-level tools make requirements of libraries and low-level utilities not available with standard distributions. This shouldn't be surprising with an environment as young as Linux, but it is still annoying. Even so, the Perl extension to the GIMP is a prize possession and shouldn't be overlooked.

The Perl-Fu interface comes with several Perl modules. The GIMP module allows access to plug-ins and filters via the standard plug-in interface, gimp_run_procedure. The GIMP::Fu module abstracts this so you call plug-ins by name. At least, this is the impression I got after reading this chapter. Check out Appendix C, which is a very good reference for writing Perl scripts for the GIMP.

The most confusing paragraph in the entire book came in the chapter on the GIMP. Here, in a footnote, Shawn makes a valiant attempt to explain the differences between plug-ins, script-fu scripts and Perl scripts. It isn't an easy read, but it was a nice try. I noticed one error in chapter 8, “Image Maps”, in reference to the GIMP: there is an Image Map tool for the GIMP now. I suspect the reason Shawn missed this is simply a matter of timing. The Image Map plug-in probably arrived after Shawn finished writing this book.

In general, the text makes a fairly poor attempt at being platform-independent. Occasional references are made to Microsoft-based tools, but many (perhaps most) of the tools discussed are UNIX-specific. I think O'Reilly may have wanted this more than Shawn did, but in either case, they probably should have stuck with UNIX only.

The chapter on animation is good, discussing the topic from a strictly programming perspective. Many of the techniques covered, such as splitting an image, often work better using interactive tools such as the GIMP. Nevertheless, much animation work is repetitive, and having programming tools for this process obviously helps. This chapter does a good job explaining the hows and whys of animation programming from a web developer's point of view.

One thing I completely disagreed with was the suggestion in chapter 10 of embedding ASCII art in HTML ALT tags. If you want to use ASCII art, as a convenience to users of text-only browsers, set the ALT tag to the appropriate text and link the tag to a separate page containing the ASCII art. Don't embed it in the ALT tag. If you do, you'll hate yourself later when you have to go back and edit that HTML file by hand.