Zoomify Operating Modes and XML file types

In working with the Zoomify viewer there is no unified approach to the system. You have to reverse engineer the operation by inspection of the 70 or so examples they give and their cryptic texts. This writing is an attempt at deriving some basic schemes of operation from the supplied material.

I began my research with the Z commands. One of the control mechanisms is to pass the viewer a string of commands thru the HTML code. They all start with the letter 'z' hence I call them the "Z" commands. There are ovr 200 of them. Among these commands is a set that loads XML files to further control the viewer. In my view the viewer would have been better controled by sending all the commands thru the HTML thus allowing both static and Dynamic versions to use the same control mechanism. But I didn't write the viewer. And it probably just grew over time as the web changed. Looking through the command list gives us these XML file loading commands:

  1. zTourPath URL path to tours folder or to the tour destinations XML file (filename assumed to be 'destinations.XML' if not included at end of path).

  2. zComparisonPath URL to comparison.XML file listing two Zoomify Image paths for display in side-by-side Comparison interface supporting synchronized navigation.

  3. zOverlayPath URL to overlays.XML file listing one or more Zoomify Image paths for display as Overlay layers. May be used in combination with standard image path parameter for base image, or with null value for image path, or in place of image path.

  4. zSlidePath URL path to slides folder or to the slides XML file (filename assumed to be 'slides.XML' if not included at end of path). When providing a slide path, set the image path parameter to null.

  5. zAnimationPath URL path to animation folder or to the animation XML file (filename assumed to be 'animation.XML' if not included at end of path). When providing an animation path, set the image path parameter to null.

  6. ZgeoCoordinatesPath URL path to geoCoordinates.XML file containing base values for latitude and longitude to support conversion of cursor pixel positions to geo-coordinates

  7. zXMLParametersPath URL to XML file containing any of the optional parameters in the Parameters List document in one XML list rather than as many HTML parameters in the web page itself

  8. zHotspotPath URL path to hotspots folder or to the hotspots XML file (filename assumed to be 'hotspots.XML

We can see that there are 8 different kinds of XML control files depending on what you are doing. This results in the first major decision point of the design for a new module. Do we design a node with a

Field for each type of file or just tell the Node what type of file we are submitting? If we use the former approach we could develop a node with the capability to send sets of control files to the viewer. Now on reviewing the data I find that we can submit an XML file which will contain all the Z command data which probably includes URI's for other XML files some of which can themselves point to other files. This is very confusing.

In the case of the node having empty files for non-needed input the input data set would be very complex to say the least. It would take some complicated code to make the input table presentable.

And you would have to deal with detecting which types of XML files were submitted some how. Either by looking for and detecting empty fields or maintaining a set of indicator flags to show which files were present.

Therefore I will define the operating modes as follows:

  1. Single Image This is a single image shown in the zoomify viewer . It is logical to allow the provision for a Overall Control XML file, a hotspot XML file and maybe a destination XML file or some combination of these files during this mode of operation.

  2. Tour The viewer supports virtual tours. The interface is a bit clunky but the hotspots can link to other nodes which grouped together represent the tour. The control file format supports audio mp3 files.

  3. Comparison The viewer allows for the comparison of two images side by side. This operation mode requires a different set of HTML data be emitted by the module. Its logical for this mode to have the overall XML as well as the Comparison XML.

  4. Slide The viewer supports a slide show type of operation. This also requires the module to emit a different pattern of HTML. Its is logical to allow the submision of an overall control XML file here as well.

  5. Animation The viewer will allow images to be animated. This application requires the loading of a great many files. One file per frame of the animation. The animation may consist of tile directory structures, directory groups of ZIF formatted frame files or raw jpeg images. I am not sure about the usefulness of the overall XML command file here.

Now the naming convention for the files. For each type of XML file the z command carries with it an assumed file name. In the examples supplied by zoomify the XML files are named with the assumed name combined with a differentiation label. As in "Destination-MyTour.xml" . Its not a bad convention to follow. It will avoid a problem in differentiating the files of different nodes since they may share the same directory. The directory structure is both important and the largest problem in adapting the Zoomify viewer to Drupal 7. I'll talk more abut the directory structure later.

At this point we are left with 8 different XML control file types and 5 defined modes of operation. I am going to propose allowing the mode of operation to control the type of XML file submitted. This will add complexity to the input form.

I also need to allow the switching on and off the coordinate display, the debug modes and the general XML file. The coordinate display could be controlled manually by adding the appropriate z command but I keep forgetting what they are. Such common requirementsas these just requires a set of flags. Easy to switch on and off.