This is a specification for a script that will display a series of photos with captions and other information. These photos will be selected from subdirectories of http://philip.greenspun.com/images/ and generally different sized versions of the same image are available in conventionally named files, e.g., foobar.1.jpg for the thumbnail, foobar.3.jpg for a 512x768 pixel version. This spec was written by philg@mit.edu on August 30, 2005. There are two sources of input for this script. One is a human-readable HTML document, e.g., http://philip.greenspun.com/photography/exhibits/newport-jazz-festival-2005 The information about which photos are good and in what sequence to show them is implicit. Given an .html file the script should do the following 1) find all of the thumbnails shown on the page and collect them into a list 2) probe the file system to make sure that .3 or .4 JPEGs are available for each thumbnail 3) return a Javascript or DHTML page that will show the larger images in sequence, the only caption being the file name (the idea behind this is that we don't want to make the server redo all of the work in Steps 1 and 2 every time the reader wishes to scroll to the next image; all of the sequencing from image to image is done in the browser and the server only responds again to requests for specific JPEG files) A typical initial invocation would look like this http://philip.greenspun.com/photography/slide-show?size=big&html_file=/photography/exhibits/newport-jazz-festival-2005.html In a real invocation the html_file value would be URL-encoded and the slashes converted to %xx. Note that the file name is relative to the Web server root. This helps a bit with security because the script ("slide-show.tcl") is going to add the server root directory before doing any file system probes. The script will still have to ensure that the file name does not contain any ".." characters and is not trying to dig below the Web server root. Given a spec file, e.g., newport-jazz-festival.ss (note the ".ss" as a conventional extension; this has the benefit of suppressing Emacs's desire to go into Auto Fill Mode when editing one of these), the script has a simpler job because it need not search for IMG tags within HTML markup. Here is the format: Title: Author: Date: Copyright link: More info link: -------------- |caption After the overall show information there is a separator line, starting with two or more dashes. After the separator, there is one line per image, separated by a Unix/Windows newline. Only the filename stub is required. If the caption field is omitted the filename stub will be used as a caption. Here's an example of a spec file: Title: Newport Jazz Festival 2005 Author: Philip Greenspun Date: August 2005 Copyright Link: http://philip.greenspun.com/copyright/ More info link: http://www.allaboutjazz.com/php/article.php?id=18719 -------------- /images/20050813-newport-jazz-festival/crowd-and-fort-wall /images/20050813-newport-jazz-festival/wynton-marsalis-septet-06|bass player for Wynton Marsalis Note that the file name stub is truly a stub. There is no need to put in a ".1.jpg" extension or whatever because the script will look for .3 or .4 JPEGs as appropriate. Here's an example invocation for a slide show, based on a spec file, featuring the .4 size JPEGs: http://philip.greenspun.com/photography/slide-show?size=big&spec_file=/photography/exhibits/newport-jazz-festival-2005.ss The JavaScript or DHTML page served should have the following properties: 1) very dark gray background 2) substantial borders around the photos so that they don't fight for the viewer's attention with whatever else is cluttering up the screen 3) small title/date/author information underneath the photo subwindow and also the copyright and mor info links 4) a "next" button that the reader can click to go to the next photo 5) an "play/pause" or "auto" button that the reader can click to sequence the photos automatically every 5 seconds The Javascript or DHTML code will have its own local data structure to keep the list of JPEGs to show. I.e., it won't have to go back to the server to figure out which photo to show next. The Javascript or DHTML code will request the JPEG but not swap it in for live display until it has be fully downloaded from the server. The slide-to-slide transitions don't have to be smooth or fancy but the reader should not be looking at a partially-loaded image. The server-side programming should be done in the AOLserver 3.2 Tcl API.