Re: Tweak for interactive SVGs?

[<pl...@pi...>]

Ethan A Merritt wrote:

> In pretty much all cases that I generate SVG plots, it is for display on
> dynamically generated pages that contain multiple plots.  Again I don't
> know that much about it, but it would seem to me that you would need a
> single copy of the script that serves the entire page, and mousing into
> the box of any individual plot just triggers a new mouse_coord->plot_coord
> transformation matrix.  I don't know if you can have multiple copies of
> the same script on the same page, separated by the scope of the 
> <svg> tags.  But maybe you can.
> 

js can be added either externally or within each <svg> tag pair.

<script type="text/ecmascript" xlink:href="scripts/gnuplot.js" />
<script type="text/ecmascript"><![CDATA[
...
]]></script>

I would favour each svg object being complete and autonomous.
Outsourcing the scripts should be regarded as (possibly) an optimisation.


As for the coordinate display, I've given this some thought and I think
there are significant obstacles to using mouse event coords and a matrix.

The main issue being how to detect zoom level in the viewer and also
scrolling of an svg that is bigger than the viewer window. (I often zoom
to max available to examine detail, after all, that is one of the
biggest advantages of using scalar graphics).

I think we would need some coordinate info in the svg output.

I'm thinking of trying:

Each line of a grid could have an onmouseover method called with it's x
or y coord , thus once the mouse has passed at least two x and two y
grid lines the current view is calibrated and your matrix upto date.
This way, current mouse coords could be kept upto date and used in
mousehover to display coords in a bubble (or in status bar of browser?).
It would mean a lot of calls to the mouseover event but there would be
little processing in it and at the time where the user is waving his
mouse around, the system is probably not doing much work in displaying
the svg anyway. This is probably acceptable.

This could potentially leave a period after a zoom or scroll where the
coord transform is out of date but it would basically work. It seems
reasonable to assume that if the user is looking for coord display he
will be moving the mouse around the plot. The calibration grid would
have to be detailed enough to minimise the dead time.

I don't think this would be the actual plot grid as it is now. It may be
better to add a second invisible grid with suitable intervals when this
sort of interactive output is requested. Since the paths would be
straight lines with two end points, this could be done with minimal
overhead in file size.

I think that outlines an implementation method as far as svg markup is
concerned.

regards, Peter.