Re: ISMAP coordinate tool

Tony Sanders <>
Message-id: <9310041825.AA02521@austin.BSDI.COM>
To: (Kevin Altis)
Cc: Jim Davis <>,
Subject: Re: ISMAP coordinate tool 
In-Reply-To: Kevin Altis's message of Mon, 04 Oct 93 09:51:16 -0800.
Organization: Berkeley Software Design, Inc.
Date: Mon, 04 Oct 1993 13:25:26 -0500
From: Tony Sanders <>
Enclosed is a proposal for how this might all work.  As this evolves
I will keep this URL updated with the latest info:

> >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/"><IMG SRC="img"></A>

#4 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
    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
        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/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
	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.