Re: Inline support for vector files (client-side imagemap)

Chris Lilley, Computer Graphics Unit (
Wed, 23 Nov 1994 14:16:27 +0100

Brandon Plewe wrote:

> I run several imagemaps now with over 50 hotspots, and
> those of us in the GIS/Mapping industry have several applications waiting in
> the wings which could conceivably have thousands of hotspots.

Does client side capability for imagemap handling preclude doing it on the
server in those cases where that would be the better choice?

> The other problem denotes that you seem to have missed one of the advantages
> of Softsource's proposal (which could just as easily be done with CGM), which
> is the ability of the browser/viewer to do zooming and panning on the file.

OK, done with either the browser or an embedded helper application.

> How would moving targets be handled with client-side imagemap definitions?

Fine, that is a problem. I had talked of moving from pixel units to physical
measurements (the HTML 3 sketch dtd uses ems) which would be needed anyway if
images were to be resampled to particular sizes (at the moment there is a one to
one pixel mapping in most browsers).

Perhaps that was not going far enough. Vector files define a world coordinate
system. Descriptions of hot locations should of course use that coordinate
system which would then deal happily with scrolling, resizing etc.

> I believe all three imagemap
> methods have their merits for different situations, and would like to see them
> all stick around.

I am tending to agree with you.

> About the standardization of CGM: I don't think it is any more difficult to
> have a working group build a standard WWW CGM profile than to build SVF.

Certain people agree with you. I will seek permission from one such to post one
of her emails to this list.

> Vision: Vector support can impact much more than distributing engineering
> drawings. If it is done right, it can lend a whole new metaphor to
> the WWW. Designers could use either (preferably both, for graphics-impaired
> users) a text-based metaphor (HTML) or a truly visual-based one (SVF/CGM),
> both with the same hypertext capabilities. The two metaphors should be
> compatible, but separable (i.e. I should have a graphics-based browser which
> can include HTML text as part of an image, as well as vice versa).

Your vision sounds interesting.