Imagemaps come in a few distinctive styles, which are essentially
graphical-design decisions. The most commonly used is what I term a
Self-Demarcating or Self-Descriptive imagemap. These images commonly have
boundaries as part of the image itself, and perhaps even descriptions of
the end of the link, so it is obvious to the browser what clicking in a
region will do. On the opposite side, there is the set of
Non-Demarcated maps, which are imagemaps that do not indicate the
destination, or often even the existence, of hyperlinks.
The Self-Demarcating maps are essentially useful as graphic
presentation of tables of contents and the like, but some uses stand out
as nearly separate categories. The first is the dynamic toolbar; these
images are generated on the fly depending on what section of a web
entity a browser is in, and the bar is an imagemap to get to other
sections. Another common imagemap is the use of a picture of an actual
map, using the natural lines of the map as the boundaries of the
different hyperlinks. The SunSite Classic Cyberspace map is an example
of a map designed after specifically for imagemaps instead of
merely manipulated for use.
To see examples of the types of imagemaps:
Important Imagemap Files
- Imagemap file
- The imagemap file handles the specification of polygons in
the image which are links. The format for each line of the file is of
type "TYPE URL Coordinates," where type is either default,
circle, rect, or poly. Default specifies
what link to follow in the case that the user does not select any other
area. Circle requires a center and edgepoint; rect
requires top-left and bottom-right coordinates; and poly allows
the user to give up to 100 vertices. All coordinates are given in the
form "x,y x,y ... x,y" (no quotations). Here is an example map file.
The most recent version of imagemap has added a point type. This
operates as a localized default; i.e., if the click is not within a
region, the point that the mouse click is closest to is chosen.
- Server configuration file
- In order to add an imagemap to the server, it is necessary to create
a map alias in the server configuration file. The file is located in the
/conf directory and is called "imagemap.conf". The format is merely of
the form, "Alias Pathname", the alias being a string used to call a
specific map through the imagemap cgi-bin file. Here is an example
server configuration file.
Tools for Imagemap Creation 
The current spectrum of imagemap assistants and tools is somewhat
limited. Investigation into three popular image manipulation tools
showed that two were no longer supported. Mapedit, however, is a useful
editor that lets the user select a type of area, draw the area with the
mouse, and then type in the URL. It then saves this information in a map
file. Click on the thumb sketch to see a screen shot of Mapedit 1.1.2.
(Note for local readers: mapedit is installed in
/usr/local/contrib/unmoderated/mips/bin.)
Tutorial on Imagemap Creation
Creation of an imagemap is a relatively simple process, though the
necessity of altering the server makes it available to few people. Talk
to your server administrator! (Note for locals: Yes, I'll help you with
your imagemaps.)
- Create a gif image that you want to map. Make sure it's a useful size.
- Choose an alias for your map file, and put in the server
configuration file (described above) a pointer to the name of your
soon-to-be-created map file.
- Create the map file. You can either find the coordinates by using
any standard image editor (for instance, xv), or you can generate
the file using an imagemap tool (like mapedit).
- Include your image inlined in an HTML page, and anchor it to the URL
"http://[site name]/cgi-bin/imagemap/[alias]". You're ready to rock!
Script programming
Introduction to Scripts
The real versatility of HTML and HTTPD servers is the ability to have
external executables be called from a browser by accessing a URL. In
this way, the server permits clients to run programs on the server's
operating system. The primary use of this ability is the dynamic
collection and presentation of information local to the server. By the
browser sending a GET command to a URL of a server-side script, the
script is executed and then returns its output across the connection. In
addition, it is possible for the browsing client to send complex argument
information to the server's program, thus allowing two-way interaction.
This section will discuss the process of establishing scripts on a
server, as well as the method of sending arguments to such scripts.
Important to note is that these scripts can currently be run in either
the Bourne shell (#!/bin/sh) or perl
(#!/usr/local/bin/perl).
The following examples all run in Bourne shell.
Establishing Scripts
Creating and installing a no-frills script is a simple operation.
Writing a script for HTML is just like writing a script to do any other
task, except for a few minor changes in the output to specify it as
HTML. Here is an example of a script that dynamically creates an HTML
page with the current time:
#!/bin/sh
echo Content-type: text/html
echo
echo "<title>Date Page</title>"
echo "<h1>Date Page</h1>"
echo "`date`"
Once a script has been created, the only remaining step is making the
script executable. After setting the proper UNIX file permissions, it is
necessary to correctly place the file so that the server will allow it to
be executed. For instance, our local server requires all executables to
be placed in either the /cgi-bin or /bin directories. A script called in
any other directory will result in the script being read as plain text
and not run at all. Once in the correct directory, calling the URL will
run the script and display any output.
Script Arguments
Creating HTML pages dynamically is a useful function, but it only
offers a small percentage of the utility of interactive shell execution.
Through arguments tacked onto the URL, we can pass arguments into the
running environment of the script. The standard method for sending an
argument is by appending a question mark followed by a single-world
argument. That argument is placed into the environmental variable,
"QUERY_STRING", and its length is placed into "CONTENT_LENGTH". The
script can then read these variables normally from the environment and
interpret them as needed. The QUERY_STRING is also passed as the first
command-line argument for the script's execution.
Unfortunately, this facility only allows a single one-word argument.
Currently, the only way around this problem is to replace spaces with
other special characters that are then replaced during interpretation.
Though the design and implementation of forms is beyond the scope of this
paper (though can be found elsewhere in this class's database), a quick
discussion of forms as a method of interaction is useful.
Forms allow the user to specify fields of text as named arguments, or
even to chose arguments from multiple-choice lists. When a form is
submitted, those arguments are concatenated into one large string
of 'name=argument' strings, separated by ampersands and with spaces
replaced by plus signs. For instance, if the user typed 'Wednesday' in
the 'day' field and '24, 1995' in the 'num' field, the URL would be sent as
URL?day=Wednesday&num=24,+1995
Server Security
The idea of allowing practically-anonymous users from around the
world to run executables locally is a frightening one to most system
administrators. Not only do they take processor cycles (sometimes
frequently!), but they also provide a possible local security breach. A
poorly-functioning script can crash, causing endless difficulties for the
server administrator since facilities for such occurrences are limited,
and bad scripts can even provide secuirty holes for malicious or even
well-intentioned but unaware users. The server administrator must select
a default user-id to be used for all script executions, which essentially
means there is a choice between allowing everyone script access, or no one.
The only practical solution is for server administrators to severely
limit access to the script-legal directories and to closely monitor the
addition of any new scripts to the server. This places an unfortunate
burden upon the administrator, but is likely unavoidable given the
current WWW communication model.
Conclusion
Though this page is not to be considered at all a survey of HTML or
server programming, it does investigate two of the most frequently used,
and most useful, extensions to plain HTML text pages. Imagemapping is a
very popular interface extension-- the Web's popularity is generally
considered to be due to the readily availble GUIs, and extending that
GUI-feel to the HTML pages is equally popular. The server-side scripts
give the web real power beyond simply concurrent browsing of static data;
and interactive programming tools will keep the Web useful and dynamic
source of information for many years.
Pointers to bibliographical information on Imagemaps and script
programming are intermingled throughout the page; other parts of the
class database should cover related topics as well.
Jan Olofsson
jan.olofsson@mbox304.swipnet.se
Denna sida ändrades 970318
