Re: link areas within images
Dave_Raggett <dsr@hplb.hpl.hp.com>
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9306240815.AA29086@manuel.hpl.hp.com>
Subject: Re: link areas within images
To: hoesel@chem.rug.nl
Date: Thu, 24 Jun 93 9:15:14 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]
> Is it too late to vote for non rectangular local(!) mouse support.
> I want to show a picture of the ruins of pompeii (shown from above at an
> angle of say 30 degree) and want people to be able to click on one off the
> wall of a building. The wall can be a line running at an arbritary angle
> over the screen,and could even be a bit irregular (around a chimney perhaps)
You are certainly not too late!
The current mechanism is uses the browser to recognise when the user
clicks with the mouse over an active region of the image/drawing:
<!-- Figure anchors designate rectangular areas on the
figure which can be clicked with the mouse. The units
are scaled from 0.0 to 1.0 for each axis. The default
area is the whole of the figure. This mechanism
interprets mouse clicks locally.
-->
<!ELEMENT FIGA - O (EMPTY)>
<!ATTLIST FIGA
href %URL; #REQUIRED -- link to traverse when clicked --
x1 NUMBER #IMPLIED -- left in range 0 to 1 --
y1 NUMBER #IMPLIED -- top in range 0 to 1 --
x2 NUMBER #IMPLIED -- right in range 0 to 1 --
y2 NUMBER #IMPLIED -- bottom in range 0 to 1 -->
To supported polygons as regions, we need a way of specifying a list of
points. The obvious way is as a comma separated list of numbers:
The following is a triangle: (0.2, 0.3) (0.23, 0.33) (0.15, 0.31)
"0.2,0.3,0.23,0.33,0.15,0.31" as x1,y1,x2,y2,x3,y3,...
> some kind of highlight on the client site is needed, so if the user moves
> the mouse over the wall (the line) it lights up or something equivalent, so
> the user can see: 'he, this part of the wall does something, lets see it' or
> 'hmm this part af the wall is connected to the part on the other side of the
> chimney, and I have seen that already. lets skip this link'
As far as I can see, the browser can handle all this automatically, without
any need for additional information. It could even examine the URL associated
with each region to select a mouse cursor appropriate to the type of linked
information, e.g. musical notes for sound sequences.
The new version of FIGA would look like:
<!ELEMENT FIGA - O (EMPTY)>
<!ATTLIST FIGA
href %URL; #REQUIRED -- link to traverse when clicked --
area NUMBERS #IMPLIED -- x1,y1,x2,y2,x3,y3,... -->
The ISMAP mechanism with XMosaic's IMG tag gets the server to process mouse
clicks, and hence can offer greater flexibility than a static collection of
polygonal areas handled by the client, e.g. the active regions could vary
with time in shape and effect.
<!ELEMENT FIG - - (EMBED?, FIGA*, (%text;)*)>
<!ATTLIST FIG
id ID #IMPLIED
float (float) #IMPLIED -- fixed or floating figures --
ismap (ismap) #IMPLIED -- mouse clicks handled by server --
src %URL; #IMPLIED -- link to image data -->
The coordinates for clicks are measured in the same units as FIGA rather than
IMG's pixel values which can't cope with objects such as drawings for which
the pixel extent will vary from one browser to the next in an unpredictable
way.
Example:
<fig ismap src="http://chem.rug.nl/geo/nl.gif">
Major population centers in the Nederlands
</fig>
A mouse click over a city is sent to the server as:
"http://chem.rug.nl/geo/nl.gif?X,Y"
with X and Y replaced by numbers in the range from 0 to 1.
In theory authors could combine both techniques. Clicks over areas defined
with the FIGA tag are handled locally, while clicks over other parts of the
image are sent to the server.
Does this seem OK?
Dave Raggett