MCML Reference and Tutorial

November 6, 1999

copy filename.ext
gen filename [ unique | uniquenamed=filename | count=n | foreach=pagename
    | xtotal=n xpadding=n [ ytotal=n ypadding=n ] ]
    [ columns=n ] [ numformat="spec" ]

albumcomment
albumtitle
htmlname
if [ not ] [ +n | -n ] test … else … /if
loopcount [ offset=n ] [ numformat="spec" ]
pagename [ +n | -n ] [ maxlength=n ]
pagenum [ +n | -n ] [ numformat="spec" ]
repeat [ count=n | foreach=pagename ] … /repeat
sourceheight [ +n | -n ] [ offset=n ]
sourcewidth [ +n | -n ] [ offset=n ]
sourcejspath [ +n | -n ] [ maxlength=n ]
sourcename [ +n | -n ] [ maxlength=n ]
sourcepath [ +n | -n ] [ maxlength=n ]
table … /table
  tablecell
  emptycell
  tablenewrow
  tablebottom
thumbcomments [ +n | -n ] [ maxlength=n ]
thumbdiskid [ +n | -n ] [ maxlength=n ]
thumbkeywords [ +n | -n ] [ maxlength=n ]
thumbname [ +n | -n ] [ maxlength=n ]
thumbheight [ +n | -n ] [ offset=n ]
thumbwidth [ +n | -n ] [ offset=n ]
thumbmaxheight [ offset=n ]
thumbmaxwidth [ offset=n ]
thumbnum [ +n | -n ] [ numformat="spec" ]
thumbtableheight [ +n | -n ] [ offset=n ]
thumbtablewidth [ +n | -n ] [ offset=n ]
usernum [ offset=n ] [ numformat="spec" ]
usertext [ maxlength=n ]

MCML ("Media Center Markup Language") is a set of instructions for dynamically creating HTML pages based upon the contents of a Jasc Media Center Plus albumfile. The user activates this functionality by first opening an albumfile, then selecting the Export to HTML menu option and making appropriate selections from the ensuing dialog.

Some general notes about MCML and its usage:

• Outside of a few specialized comments for looping and conditional selection, MCML is essentially a preprocessing macro language for HTML ("Hypertext Markup Language") files. In other words, all MCML instructions are evaluated and removed before the remaining HTML code is even considered, and a majority of the available MCML instructions result in some line or block of text being substituted for the MCML instruction at that same location when the output file is created.
• The output of processing a single MCML file once through is a single HTML file. A single MCML file produces more than one HTML file only when it is itself processed more than once. The MCF file specifies how many times each MCML file is to be processed.
• A single MCF file, one or more MCML files, and optionally other non-MCML files, collectively make up a site design. Each site design is stored in an appropriately-named subdirectory underneath the main "MCML" directory, which in turn is underneath the application directory for Jasc Media Center Plus. The name of the site design that is presented to the user as an option (whenever they perform an Export to HTML operation) is the name of the subdirectory in which the site design is stored.
• Thumbnails will always be exported from the Export to HTML engine in the same order in which they appear in the albumfile.
• It is not necessary for MCML files to check what subset of files from an albumfile is being exported. All such details are taken care of automatically by the Export to HTML engine.
• MCML does not support output of HTML or related files to multiple directories. All files that are created and/or copied by the Export to HTML process will be placed in a single output directory.
• Generated HTML files are always assigned the extension ".htm".
• All MCML instructions (with the exception of the pair of instructions that are used in the MCF file) are implemented as tags, very similar in form to HTML tags. They consist of an opening angle bracket ‘<’, the word "MCML", a following set of clauses that identify the specific MCML instruction and any optional arguments associated with it, and finally a closing angle bracket ‘>’ to mark the end of the tag.
• MCML tags cannot be split across multiple lines; i.e., the opening and closing angle brackets ‘<>’ of any individual MCML tag must appear in a single line of text.
• MCML is not case-sensitive, except in the instance of the numformat clause (an unavoidable exception, since printf() format specifications are case-sensitive).
• MCML does not care in what order instruction clauses appear.
• MCML is non-recursive … i.e., an MCML tag cannot be embedded inside the angle brackets ‘<>’ of another MCML tag and expected to be interpreted properly.
• MCML does not support nesting of repeat loops and thumbnail tables … only one of these can be used at a time. Nesting of conditionals (if statements) is supported, however.

NAME

The gen instruction is used in the MCF file to identify MCML files that are to be used for the generation of HTML files whenever an albumfile is exported using the current site design. Each MCML file should be regarded as the description of a single page type.

A maximum of one "size" clause can be selected for each gen command, as they are mutually exclusive. The "size" clauses are as follows: unique, uniquenamed, count, foreach, and the inter-dependent set of clauses xtotal, xpadding, ytotal and ypadding. If the referenced MCML file is to utilize a thumbnail table, either the xtotal and xpadding clauses or a foreach clause referring to another MCML file that used the xtotal and xpadding clauses must be used.

If only xtotal and xpadding are given, the export engine uses them to determine the number of columns of thumbnails to create, and outputs all thumbnails to a single page. If the ytotal and ypadding clauses are provided in addition to xtotal and xpadding, the engine will determine both the number of columns and rows that will be created, and will generate one or more HTML pages as needed to display all exported thumbnails.

Note that the ytotal and ypadding clauses may not appear without the corresponding xtotal and xpadding clauses. In other words, the export engine will not create an HTML page with a fixed number of rows and an infinite number of columns.

Each generated HTML file will be given the same name as the source MCML file, plus a unique number (only if multiple pages could be created by the gen instruction) that is formatted as specified in the numformat clause, and the extension ".htm". The only exception to these naming conventions is when the uniquenamed clause is used.

When the foreach clause is used, the MCML page to which it refers must have appeared earlier in the same MCF file (on its own gen command line).

An explanation of the meanings of various text styles in the Synopsis portion of the following reference pages:

The albumcomment instruction is replaced by the album comments text for the album being exported, if any.

If no text is available, the instruction will simply be removed and nothing will be inserted in its place.

The easiest way to get started in creating site designs using MCML is to first design an HTML page with the desired appearance. (Obviously it will be helpful to keep in mind the sorts of things that MCML can and cannot do as you are designing the HTML.) As you become more comfortable with MCML you might decide to create site designs from the ground up in MCML, without an ensuing HTML step, but a distinct advantage to designing the HTML first is that you can more easily see what works visually, and what doesn’t. We will take this approach as we create a fairly simple HTML site design and then convert it to MCML so that it may be generated automatically by the Export to HTML capability of Jasc Media Center Plus.

We’ll start by writing some straightforward HTML for showing one or more pages of thumbnailed images:

Notice that we added a place near the top of the page for links to multiple pages. Exactly which chunks of text are linked, and to what names, don’t matter to us right now; we just needed to decide how we wanted linked text and non-linked text to look. For the same reason, we added enough thumbnails (just using the same image file for each) to create a table with multiple rows and multiple columns, so that we feel comfortable with how the spacing will look. We also made sure to use some empty cells on the last row, for reasons that will become clear later.

When we view this page with a web browser, we see something like the following screen:

Now let’s get started on creating an MCML file for this page design. Copy the HTML file to a new filename, "default.mcml", and open that file for editing with a text editor. (We use "default" whenever we want any HTML pages generated from this MCML file to be named with a name specified by the user; we could chose another name, but then the HTML files would have that name as well.)

First let’s take care of some of the easiest changes. Right at the top of the file we see some page titles that currently say "Gallery":

Wouldn’t it be nice to have the title of the albumfile shown in those places instead? To do so, we only need to substitute the appropriate MCML tag for each occurrence of the title "Gallery", that tells the Export to HTML process that we want the current albumfile title to appear here instead. The MCML tag we need for this is the albumtitle tag:

Note that we are only using capital letters for the "MCML" portion of each of the MCML tags to set them off from the surrounding HTML text. Like HTML tags, MCML tags are not case sensitive; we could just as easily use all capital letters for the HTML tags and all lowercase for the MCML tags in order to differentiate them, or the same kind of letters throughout if we aren’t concerned about it.

Now let’s get down to the core of changing this page into MCML. The primary difficulty we have to address is to figure out how to place thumbnails within a table using MCML. What makes this hard is that, unlike when we design an HTML page, we can’t know exactly how many thumbnails are going to be in the table when it is actually generated (during an Export to HTML process). What we need to do is divide up the different changes that occur during the generation of a table, and tell the Export to HTML engine (via MCML instructions) what to do for each of those changes.

Here is the basic set of "tasks" for generating a table in HTML, in order of execution:

1. Start the table with "<table>" and begin the first row with "<tr>"
2. Create cells (columns) with <td> … data … </td> until we get to the end of the row
3. End the row and start a new row "</tr><tr>"

(3.1. Repeat steps #2 and #3 until we get to the end or run out of data)

4. Optionally create empty columns to the end of the row if we run out of data in the middle of a row (to maintain the alignment of columns with the preceding rows)
5. End the table with "</tr></table>"

Since step #3.1 is simply a repeat of steps #2 and #3, we can see that there are five different "tasks" that happen in the course of creating a typical HTML table. Two of them (#1 and #5) only happen once (at the start and end of the table, respectively), and the other three may be repeated many times in between.

When creating an MCML file, our task is to provide information about each of these five tasks to the Export to HTML engine, so that it can build the table as it needs to, depending upon the set of thumbnails it has to work with. To do this, MCML provides a unique instruction to label each of the five required tasks. Those labels, numbered to match the tasks described above, are:

1. Table
2. Tablecell
3. Tablenewrow
4. Emptycell
5. Tablebottom

To begin a table in MCML, we always start with the <MCML table> tag, which also marks the beginning of the "task #1" block of code. Then, we insert each of the other "sub-tags" as needed, to mark the blocks of code that are needed for the rest of the "tasks". After we have provided all of the needed information, we end the table with the <MCML /table> terminating tag. The other four tags are considered to be "sub-tags" of the table tag … they are only valid within a block of MCML table information. There are no terminating tags for any of the table sub-tags; the MCML interpreter assumes that whatever text follows such a tag is part of that section of the table, until either another sub-tag or the overall table terminator is encountered. All of the subtags are optional; if any of the sections is not provided, then no text will occur in the HTML output file whenever that part of the table is being generated. (Generally, however, most of these sub-tags will be needed.)

Now, how do we take all of this information and create a working MCML table? Believe it or not, it’s much easier than the above may have made it sound. Here is the table portion of the original HTML code we are working from, with each line numbered with the task it represents (as defined earlier):

Notice that the lines associated with task #2 (individual cells of data) are actually a number of repeats of almost exactly the same two lines. If this table had more than two rows of data, there would similarly be multiple groups of lines associated with task #3. The number of times those groups of lines need to be repeated depends entirely upon how much data is being shown in the table … but that is for the Export to HTML engine to determine, and not our job. We only need to tell the engine how to create a single cell (for task #2) and how to start a single new row (for task #3).

Here is the above table, after having been initially divided into sections and labeled with the appropriate MCML tags:

Notice that all of the HTML table tags for rows, columns, and the table itself still need to be included in the text; the only job of the MCML tags is to identify the various table sections to the Export to HTML engine. This is because it is very often desirable to add additional arguments to the HTML table tags, in order to make things look exactly like is intended. Furthermore, it is quite possible to create an MCML table that doesn’t actually generate an HTML table, but rather some other sort of arrangement of thumbnail data … this would not be possible if the MCML table tags always "forced" the equivalent HTML tags.

(Most MCML tables will look a lot like the above … so much so that it may behoove MCML designers to save a copy of a table like the above as a template for the creation of future MCML tables.)

But we’re not done yet. If we stopped here, the generated table would have the correct number of rows and columns (matching whatever set of thumbnails are being exported at the time), but all of the cells would still show a single image and name, specifically "shot17.jpg". That wouldn’t be very useful!

This is easily solved, but first we need to briefly touch on one of the tasks that the Export to HTML engine performs when it is executed. Whenever thumbnails are being exported by the Export to HTML process, and those thumbnails have individual thumbnail images associated with them, the program creates a set of small image files (we’ll be referring to them as "thumbnail files") in the output directory, one for each of the thumbnails. It also keeps track of the unique names it has assigned to each of those thumbnails, so they can be used during the generation of HTML files. The names of these thumbnail files will usually have nothing in common with the source image files they are associated with, so you can’t "guess" as the filenames in your MCML files … you have to use the MCML thumbname instruction to get at them. We have a similar MCML instruction, sourcename, that will give us the name of the actual source file the thumbnail is associated with … this is the appropriate tag to use when showing the name of the file to the viewer.

If you’re wondering about how to define which thumbnail name is selected in a table with multiple thumbnail names, you can relax … you don’t have to! The Export to HTML engine is smart enough to automatically provide information (whether that information be filenames, source names, comments, keywords, or whatever) for the correct thumbnail for each position within the table. All you need to do is tell it where to put that information in a single cell, and the engine does the rest for you.

Here is the tablecell code that we want to change to refer to the correct thumbnail and source file names:

Once we’ve replace the references to "shot17.jpg" in the above code with the needed MCML tags to get the correct filenames, we end up with this:

Pay special attention to the fact that the MCML tags appear inside quotes on some of the above lines. Remember that, as described in the Overview section of this document, MCML works by replacing its tags with plain text, which is then evaluated as HTML whenever the generated page is viewed in a browser. If the text (such as the source name above) may have a space in it, and having a space in it would require the text to be quoted in the HTML tag, then the MCML tag itself must be quoted as well. The advantage of this is that it allows the same MCML tags to be used in any context within the HTML document … you don’t have to remember different MCML tags for using the name in an HTML tag, versus simply printing the name as text.

But wait a moment … what’s this "maxlength" thing in the last MCML tag for? If you look back at the original HTML code, you’ll note that the last reference to "shot17.jpg" is actually printed as plain text below the thumbnail image of the file.

One problem with not knowing in advance what source files will be included in our generated HTML files is that filenames can easily be long enough to screw up the appearance of our HTML. (The reason web designers don’t usually encounter this problem is that they know all of the files that will be included, and can alter names and formatting to suit their needs.) What we need is a way to keep filenames from becoming so long that they screw up the appearance of our HTML output. But when you consider that the size of text shown in a browser can vary based upon the selected font, settings on the browser, settings on the viewer’s computer, etc., you realize that it is virtually impossible for the export routine to be able to pre-calculate text lengths to avoid such problems.

One solution is to provide a simple capability to never use more than a certain defined number of characters; when used properly, this can prevent such problems in 95% of cases. Accordingly, all of the MCML tags that output text data about thumbnails include an optional maxlength clause to do this. If the maxlength clause is not used, all characters available will be sent to the output, so make sure you’ve thought carefully about this before using (or failing to use) the maxlength clause. Note that you will never want to use maxlength for a filename being embedded within an anchor "<a>" or image "<img>" tag, as the filename will obviously not be valid if some of the characters have been cut off. The maxlength clause need only be considered when a filename is to be shown as plain text, and is particularly valuable when that text is to appear in a table or any other tightly formatted HTML construct.

The full MCML file now looks like this:

But before we can use this MCML file with the Export to HTML function, we need to create one more file. This file is always named "default.mcf", and we’ll refer to it as the "MCF file", or the "master control file" (with obvious acknowledgements to the movie TRON).

The MCF file is the first file at which the Export to HTML export engine looks. It tells the engine where to find all of the MCML files that need to be used to create the associated site design … and, perhaps even more importantly, how to determine the number of pages to create.

Each line in an MCF file will be either a copy command or a gen (generate) command. Copy commands simply instruct the Export to HTML engine to copy the named file to the output directory without modification. These may include static image files (backgrounds, common thumbnails, etc), JavaScript source files, HTML files that will never need to be altered, etc. MCML files should never be used with the copy command.

Gen (generate) commands, on the other hand, indicate the location of MCML files that need to be processed to create HTML files for the site. These lines also describe how the engine should go about deciding the number of files that need to be created. There are a number of different ways in which this can be specified, depending upon the needs of the site design. (For full information on all of the methods that are available, see the reference page for the gen command.)

For our purposes, let’s tell the export engine to fit as many thumbnails as possible into the table, without making the table so big that it always requires scrollbars on the browser. Here, then, is the single command that needs to be in our default.mcf in order to export web pages in our new site design:

In the above line, "default" is the name of the MCML file (it must appear without the ".mcml" extension). The rest of the clauses that appear on the line work together as a unit to describe the amount of space available for a table of thumbnails in this MCML page.

The xtotal and ytotal clauses define the amount of space (in pixels) horizontally and vertically that should be treated as available for the display of thumbnails in a table. Not that with the values we’ve specified above, a full page of thumbnails will still create a vertical scrollbar for users with their screen resolution set to 640x480 (because the title information, browser menubars, etc. also use up some of the available vertical space). We could shrink the ytotal value even further to prevent that, but we don’t want to make the table so small vertically that we leave large amounts of the screen unused at higher resolutions, so we’ll leave it like this. (Making these types of choices should be a familiar process to anyone who has ever designed a web page … the need for such decisions is not specific to the Export to HTML function.)

The xpadding and ypadding clauses define how much space (again in pixels) above and beyond the native thumbnail size is required for each thumbnail. Example: a table cell may be formatted in such a way that it includes borders and or text around the thumbnail, which of course uses up some amount of extra space on the screen between thumbnails. The amount of extra space that is required by such additions is what should appear in the xpadding and ypadding clauses.

When the Export to HTML process actually runs, it uses this information, in conjunction with its own information on how many thumbnails are being exported and the native thumbnail size of those thumbnails, to determine how many thumbnails can appear on each page of our design. Then it can determine how many HTML pages will need to be generated from our single MCML page in order to have exported all of the thumbnails.

(A programmers’ note: if you’re wondering why this table size information couldn’t simply be embedded in each of the individual MCML files, consider that one MCML file may at times need to ask for information about the number and/or layout of other MCML files. That, plus the requirement for the copy command, necessitates a separate, "top-level" file for such information.)

Now that we have our two files, "default.mcf" and "default.mcml", we are ready to try the site design out in Jasc Media Center Plus for the first time. To do so, we need to install this site design in a subdirectory below the "MCML" directory, which is in turn below the main application directory where Jasc Media Center Plus resides. Create a subdirectory called "Tutorial" under the "MCML" directory, and copy our two files into this new directory. (The directory name, "Tutorial" in our case, is important because it is this directory’s name that will be shown to the user in the Export to HTML dialog when they are choosing which site design to use.)

Now we are ready to run Jasc Media Center Plus, load or create an album of images as usual, select Export to HTML from the File menu, and select the "Tutorial" site design from the drop list in the Export to HTML dialog. If we get any error messages after clicking on the OK button, we need to go back and look at our MCML code to make sure we didn’t make any typing errors.

If the Export to HTML process completed without any error messages, the result should be one or more HTML files in the output directory that we selected. And when we double-click to view the first HTML file in a web browser, it should look something like this:

Note that the number of thumbnails shown may vary from this example, depending upon the native thumbnail size of the album that has been exported. We’ll talk more about that later. Also note that the user’s specified filename will always have a number appended to it with this design, even if only one page of thumbnails has been generated. This is necessary because we have not defined the default page type as unique, and anytime that a page type is not defined as unique, all filename functions of the Export to HTML engine (not to mention loops in the MCML pages themselves) have to assume that more than one page might be present. This can be avoided by always creating a unique default page type (such as a framed titlebar, or a menu page for selecting one or more actual thumbnail pages).

This page doesn’t look too bad … however we can easily see a few things that need further adjustment. The most obvious one is the index of page numbers at the top; it isn’t changing to match the number of pages of thumbnails that may have been created during the export process, and that hardcoded link to page 2 certainly doesn’t point to the correct HTML file either. Obviously we still need to add a little bit more intelligence to our MCML file so that it will work properly no matter how many or few pages of thumbnails we throw at it, and so that the viewer can access all of the pages that are generated.

Here’s the block of HTML that needs to be changed:

If this task required a separate entry for each thumbnail we would use an MCML table instruction. However, what’s needed here is an entry for each HTML page that is being generated from this MCML file. For such circumstances, MCML provides a different, more generic way to output a block of text multiple times – the MCML repeat instruction. This instruction can be set to loop a fixed number of times, or (more useful for our needs here) to loop once for each generated page of a particular page type. A terminating /repeat tag encloses the set of lines that are to be repeated.

For our purposes we will just be using the same page type that is currently being generated (since it is the only one we have created for this site design). It is very worthwhile, however, to note that repeat can be used to loop based upon page types other than the current, a capability that is invaluable when creating a site design with multiple page types (one that utilizes frames and menus, for example).

We will use the repeat instruction to show the correct number of pages, but the next question is "how are we going to show the different page numbers?" The answer to this is another MCML instruction that is only found within repeat loops – the loopcount tag. Internally MCML keeps a numeric variable that is initialized to 1 when a loop starts, and increments by 1 upon each subsequent execution of the loop. The loopcount instruction simply takes this number and drops it into the text output at the specified point. As you will see shortly, we will be making use of this instruction in both the text output and the HTML anchor tags of the index section of this design.

But there is still one more issue that must be addressed. We would like for the current page number in the index to not have a link (because any such link would cause it to refer to itself pointlessly, and also because having the current page shown without a link helps identify the current page to viewers).

For this task MCML provides another instruction that will be familiar to those with programming experience – the if instruction. This instruction allows a block of text (optionally including other MCML instructions) to be used or skipped, depending upon the results of a particular test that is performed by the if instruction. As with the repeat instruction described earlier, a terminating /if tag marks the end of the group of lines that are to be used or skipped depending upon the results of the test.

There are a number of different types of tests available for use with the if tag, all of which are fully documented on the reference page for the if instruction. For our purposes we will be using a single test called loop_eq_page, which tests if the loopcount value matches the current page number. Note that this particular test can only be used inside a repeat block (because it uses the loopcount value), and that it can only test the page number of the current page type (there is no "current page" for page types other than the current type).

After incorporating all of the above, the resulting MCML for creation of the index of page numbers looks like this:

Note the MCML else statement that appears in the middle of the if block. This should be familiar to anyone who has done any programming … it specifies that the block of code following it should be used if the test in the enclosing if statement failed, rather than succeeded. Therefore, the code here outputs a page number without a link "if the loopcount equals the current page number" … otherwise it outputs the page number with a link.

Also note that we need to build the filename for the HTML anchor tag ourselves, using the name that the user assigns to the page (remember, since this is the ‘default.mcml’ file, the HTML files will be renamed to the user’s selected name) and the loop counter.

We’re almost there, but there is one more thing we should consider. The export process is already calculating the number of thumbnails to show based upon the native thumbnail size of the albumfile in question, but as seen in the lines below, our MCML is always forcing the thumbnails to be 80 pixels wide:

But what if we want to display the thumbnails at their full resolution, no more and no less? To do this, we would need to dynamically change all of the numbers shown in the above lines to match the size of the thumbnails in the exported album.

MCML provides numerous ways to retrieve thumbnail and image size information, each of which vary slightly in their functionality to fit the specific needs of the site design. For our purposes we will use three of these instructions, thumbmaxwidth, thumbmaxheight, and thumbtablewidth:

• thumbmaxwidth and thumbmaxheight always returns the native thumbnail size of the current album. We will use these to set the size of the individual cells of the thumbnail table.
• thumbtablewidth is slightly different in that it returns the width that the thumbnail will have to be, without changing the aspect ratio (ratio of width to height), to use all available space in a thumbnail table cell that has been sized to fit the native thumbnail size of the current album.

All of the MCML instructions for returning thumbnail sizes also provide an optional offset clause, which can be used to adjust the returned size by some positive or negative integer value. We will use this with thumbmaxwidth and thumbmaxheight to leave some extra space between the thumbnail images, and to allow room for the filename. Looking at the above MCML lines, and remembering that we designed the original page with 80x80 thumbnails in mind, we can see that we allowed 40 pixels of extra horizontal space and 30 pixels of extra vertical space for each cell of the table, so we’ll use those values for the offsets. (If you go back and look at the "default.mcf" file for our site design, you’ll see that the xpadding and ypadding values exactly match these offset values, and not by chance either.)

Here, then, are the changes we’ll make to the table cell section:

After all of the changes listed above have been incorporated, the final MCML file looks like this:

Now, when we export an album with a native thumbnail size of 120 x 120 to our site design, we get output that looks something like this:

And if we then export an album with a native thumbnail size of 60 x 60 to the same site design, we get something like this:

Notice that both exported albums now occupy roughly the same amount of room horizontally in the browser window, even though the size of the thumbnails has changed greatly. This now works because we have given the Export to HTML engine enough information to be able to recalculate the page and table contents based upon the contents of the exported album. Also notice how the number of pages shown in the index at the top of the screen was changed when the size of the thumbnails changed (since the number of thumbnails that could appear on a single page was altered).

This is only the beginning of what is possible when creating site designs with MCML. For example, we could easily use ‘if page’ tests combined with relative addressing for HTML pages (using pagename) and a couple of image files (which we would include by using the copy command in the MCF file), to provide graphical arrows for moving back and forth through the pages. We could add ‘if filetype’ tests and handle any non-image thumbnails in a completely different manner from image thumbnails. We could create a separate MCML source to generate a framed menu of pages. We could display other information about the images, either under the thumbnails or on separate, linked pages. We could create tables of thumbnails that only give file information and links, rather than actually showing the thumbnails. Indeed, the possibilities are very nearly endless.

Now it’s your turn. Jump in and try something!