> >Has anyone yet built a tool to facilitate creating the sets of
> >rectangle definitions needed for an ISMAP image? I have one
If we going to do this it would be nice to standardize the format
of this file so all the servers interoperate. I think we understand
the problem well enough to solve it.
#1 We should assume HTTP/1.0 with support for 302 (forward)
and content-type encoding. Otherwise there are lots of restrictions
and problems to worry about. By the time you get the tools done
I expect most browsers will support these (NCSA Mosaic 2.0pre4 does
so that means others will probably follow).
#2 We need to consider the various forms of object encoding. Rectangles
are probably the most straight forward. Also bitmasks (XBM and XBMRAW),
pixmasks (XPM), triangles, circles, and general polygons. You probably
want to tell the tool which modes your server supports. If you guys
write a tool that outputs triangles, rects and XPM files then that is
what servers will support.
#3 The reference should look something like this:
<A HREF="http://server/path/thingy.map"><IMG SRC="img"></A>
#4 thingy.map is what we mostly need to standardize. How about this:
default URL
Either the client doesn't understad ISMAP or none of the
object matched. Probably returns a menu or an error message.
If undefined then a menu will be generated using the
menu_description fields (I'm flexible on this part, I would
be happy to just return an error if people don't think this is
useful).
title menu_title
This is simple the title of a menu that is generated if
the client doesn't support ISMAP and no-spacejump isn't defined.
This basically lets you embded the default behavoir in the config
or define an external URL to access. For example: if you are
serving weather reports from a weather map you might use
no-spacejump http://rs560.cl.msu.edu/weather/getmegif.html
to rediect them to a fillout form version.
default URL [menu "menu_description"]
This URL is returned if nothing else matches. If not present then
it generates
xbmobject URL OBJECTFILE [menu "menu_description"]
textual xbm files (just like you get out of bitmap)
xbmraw URL OBJECTFILE width height [menu "menu_description"]
xbm files converted to raw data (what plexus supports)
xpmobject URL OBJECTFILE [menu "menu_description"]
xpm files (lets you defined multiple object masks in a single file)
rect URL x y width height [menu "menu_description"]
rectangles (upper-left at x,y extents width,height)
circle TBS [menu "menu_description"]
triangle TBS [menu "menu_description"]
poly URL x,y x,y x,y [x,y ...] [menu "menu_description"]
When the server gets a request for *.map file it grabs the query part
and passes it onto the decoder which then figures out which object
matched and returns the corisponding URL in a 302 "forward" reply.
This is how 302 replies work. http://www.bsdi.com/test-cases/HTTP/302.www
replies:
HTTP/1.0 302 Temporary Relocation URI follows
Last-modified: Sunday, 03-Oct-93 19:32:54 GMT
Date: Sunday, 03-Oct-93 19:37:52 GMT
Server: plexus/3.0i
Location: http://www.bsdi.com/test-cases/HTTP/302.html
MIME-version: 1.0
Content-type: text/html
<TITLE>Return Code: 302 Temporary Relocation URI follows</TITLE>
If you see this message then it didn't work.
<A HREF="/test-cases/HTTP/302.html">This</A> is what you should have seen.
It expects the browser to automatically retrieve the URL pointed to
by the Location: header.
--sanders