today | current | recent | random ... categories | search ... who ... syndication

On slideshows :

Before the templating engine, before the database abstraction class and before the weblog API there was the slideshow tool. We've all written them. They all suck. Partly because there is too much to keep track of and every widget tries to accomodate every step : the images; the scaled images; the list and ordering the of images (how many times have you sullied your file names with 0045_ prefixes?); the meta data or commentary associated with an image; the look and feel of the actual webpages. And while an all-in-one package is always fun my experience has been that, in a slideshow, context, they usually come at the price of zero-flexibility. Apache::Album is a pretty good example. It is a very cool and very easy widget to set up. But, the HTML is hard-coded and meta data is stored free-form in YA file that sits in the image directory and it only outputs HTML. So, I spent the better part of two months, a while back, tearing the guts of the package apart trying to make it more flexible with things like subclasses for output formats, XPath-itis for meta data and all manner of bells and whistles. I learned a bunch of stuff in the process but ultimately failed to create anything more flexible or robust. One of things I learned is that you can use ImageMagick to read and write comments into image files which got me thinking that you could store all of your metadata as an XML blob in the comments field. Which is pretty interesting since when you think about it a directory listing is basically a bare-bones slideshow. With some clever caching techniques you could simply attach a server based handler to a directory of images -- we'll ignore how you get the meta data in there for the moment -- and be done with it. Neat, huh? But I'm not a scholar on image formats and I don't really know what the rules are about one application respecting the comments that another application writes. And truth be told, I'm not that interested in learning. So, that means we're back to the stage where we've got a bunch of images and a bunch of XML files. Or maybe we've got just one XML file. Either way, we've got this funny bird that needs to be massaged before anything can be done with it. And writing any kind of DTD is going to be a pain because everyone is going to have some kind of random meta-ness they want added to their slideshow. Attentive readers (or David who got to listen to this rant, last night) will have begun to see where this is going:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

          "" [





By redefining the XHTML %Block; and %Flow; entities, you can create a flexible slideshow format that is both XML fit for munging/transforming and HTML for easy viewing :

<!ELEMENT abstract (p*)>

<!ATTLIST abstract id    ID    #REQUIRED

	           class CDATA #IMPLIED

                   style CDATA #IMPLIED

		   title CDATA #FIXED "Abstract">

<!ELEMENT slide (meta*,a)>

<!ATTLIST slide  sid    ID    #REQUIRED

	         class CDATA #IMPLIED

                 style CDATA #IMPLIED>

<!ENTITY % Block "(abstract,ul)">

<!ENTITY % Flow "(slide)">

The ul (yeah yeah, it should probably be an ordered list...) element can only contain li elements. li elements are defined with the %Flow; parameter entity which means you can redefine your XHTML document to validate as a single list, that contains one or more items. Each item contains a "slide" which consists of zero or more meta tags (remember them?) and a link. If all your fancy pants server tools are broken you're still left with a list of named images that link to actual images. Not great but better than than an XML document rendered as a collapsible outline. So far, so good. But wait! There's more :

  <Directory /path/to/image/directory>

   DirectoryIndex       index.html

   SetHandler   perl-script

   PerlHandler  Apache::ImageViewer

   PerlSetVar   ScaleSmall      25%

   PerlSetVar   ScaleMedium     50%

   PerlSetVar   ScaleLarge      75%

   PerlSetVar   ScaleThumb      x50

   <FilesMatch "index\.html$">

    PerlModule            AxKit

    SetHandler            perl-script

    AxProvider            Apache::AxKit::Provider::Filter

    AxAddStyleMap         text/xsl        Apache::AxKit::Language::LibXSLT

    AxAddProcessor        text/xsl        /site/xsl/slides/slide-tools.xsl

    AxCacheDir            /usr/local/www/htcache

    AxDebugLevel          0

    AxStackTrace          Off

    AxLogDeclines         Off

    AxNoCache             Off

    PerlHandler          AxKit



And while the example cited is mod_perl specific, there isn't much to prevent it from being implemented in whatever environment suits your fancy. All you need is a widget that can speak to ImageMagick and an XSLT engine that can suck in CGI parameters : sid and scale. Those are the keys used to 1) tell the stylesheet whether or not to render an image or an index and 2) tell the image widget which image to display and how big it should be. The next step is to write an XSLT stlyesheet to convert the XHTML described above in to an AxPoint document. download : slide-tools 0.1

refers to


I wrote an AxPoint DTD ←  → The dictified word of the day is : incontrovertible