gnuplot-beta — Developers and beta testers of new gnuplot code

links to gnuplot online documentation

[Ralf J. <jue...@cs...>]

Hello,

I am working on a language interface for gnuplot
which is pretty close to the gnuplot plotting command
language. For instance, for every plotting style my
interface has a corresponding function for adding
a line to a graph/plot.

I want to take advantage of this close correspondence
and refer to the gnuplot online documentation in the
help texts for my interface. I see that the online
documentation for the current development version
has anchors to the plotting styles, like

http://www.gnuplot.info/docs_4.3/gnuplot.html#lines.

Will this url eventually be

http://www.gnuplot.info/docs/gnuplot.html#lines

? The current link to plotting style 'lines' is

http://www.gnuplot.info/docs/node254.html

which does not look like a stable url. Are there plans
for more stable and systematic urls to the gnuplot
online documentation?

Thanks,
Ralf

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 28 December 2008, Ben Abbott wrote:
> 
> On Dec 28, 2008, at 4:12 PM, Ethan A Merritt wrote:
> 
> > On Sunday 28 December 2008, you wrote:
> >>
> >> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote:
> >>
> >>> On Sunday 28 December 2008, you wrote:
> >>>>
> >>>> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote:
> >>>>
> >>>>> On Sunday 28 December 2008, Ben Abbott wrote:
> >>>>>>
> >>>>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
> >>>>>>
> >>>>>>> On Saturday 27 December 2008, Ben Abbott wrote:
> >>>>>>>>
> >>>>>>>> I've concatenated several plot streams produced by Octave to
> >>>>>>>> demonstrate what
> >>>>>>>> I am seeing. The file is attached.
> >>>>>>>>> Just type the command below. The resulting plot should grow in
> >>>>>>>>> height each
> >>>>>>>> time it is plotted.
> >>>>>>>
> >>>>>>> I see no change in the plot window size; each plot is redrawn
> >>>>>>> exactly on top
> >>>>>>> of the previous one.  My machine is running
> >>>>>>> x11-server-xorg-1.4.0.90
> >>>>>>> kdebase-kdm-3.5.9
> >>>>>>>
> >>>>>>> I think that to debug this we will need to know your operating
> >>>>>>> system
> >>>>>>> environment, and in particular the window manager and the X- 
> >>>>>>> server
> >>>>>>> being used.
> >>>>>>>
> >>>>>>
> >>>>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1.
> >>>>>> If by
> >>>>>> "operating system environment" you're looking for more than I  
> >>>>>> gave,
> >>>>>> let me know what it is you'd like to see. For more info on  
> >>>>>> XQuartx
> >>>>>> see
> >>>>>> the link below.
> >>>>>>
> >>>>>> 	http://xquartz.macosforge.org/trac/wiki
> >>>>>>
> >>>>>> I've spent some time reducing the number of gnuplot commands  
> >>>>>> needed
> >>>>>> to
> >>>>>> produce the problem. If the 4 lines below are placed iteratively
> >>>>>> in a
> >>>>>> file, the resulting window progressively grows taller (with the
> >>>>>> title
> >>>>>> bar being static).
> >>>>>>
> >>>>>> 	set terminal x11 size 560,480 position 440,106
> >>>>>> 	set multiplot;
> >>>>>> 	plot x
> >>>>>> 	unset multiplot;
> >>>>>>
> >>>>>> I've attached another file for this simplified example.
> >>>>>>
> >>>>>> In any event, the problem appears to only exist (for me) in
> >>>>>> multiplot
> >>>>>> mode. I also noticed that the final window height is not always  
> >>>>>> the
> >>>>>> same.
> >>>>>
> >>>>> Could you please try adding the command "unset mouse" to the
> >>>>> beginning
> >>>>> of your test script, and check whether that makes any difference?
> >>>>
> >>>> bingo!
> >>>>
> >>>> When "unset mouse" precedes the first "set terminal x11 ..."  
> >>>> command
> >>>> the resulting plot is unaware of the mouse.
> >>>>
> >>>> However, when I tried ...
> >>>>
> >>>> 	set terminal x11 size 560,480 position 440,106
> >>>> 	set multiplot;
> >>>> 	plot x
> >>>> 	unset multiplot;
> >>>> 	unset mouse
> >>>>
> >>>> The tracing of the cursor still works.
> >>>>
> >>>> Is this behavior expected/intended? ... meaning; Are the mouse
> >>>> actions
> >>>> enabled when the mouse is set and the 1st "set terminal [...]"
> >>>> command
> >>>> is encountered? ... and that subsequent "unset mouse" commands will
> >>>> not turn the mouse actions off?
> >>>>
> >>>> Ben
> >>>>
> >>>> p.s. when the mouse actions are active my x11 window extends down a
> >>>> bit. My impression is that the degree to which it extends is the  
> >>>> same
> >>>> as the amount the window grows, I assume this was what your were
> >>>> thinking?
> >>>
> >>> Yeah.  Not that it really explains anything.
> >>>
> >>> I'll make a wild guess that the problem is related to the code
> >>> introduced by the comment at line 4284 of gplt_x11.c
> >>>
> >>> 4284:
> >>> /* it seems to be impossible to distinguish between a
> >>>  * resize caused by our call to XResizeWindow(), and
> >>>  * resize started by the user/windowmanager; but we can
> >>>  * make a good guess which can only fail if the user
> >>>  * resizes the window while we're also resizing it
> >>>  * ourselves: */
> >>>
> >>> It claims to be working around various window-manager quirks.
> >>> You could try commenting out various sections of that code, or
> >>> adding debug statement to keep track of which code path is being
> >>> triggered. It may be that an additional test, or conditional code
> >>> for Mac OSX, could bypass the problematic code path.
> >>
> >> I'm unskilled unskilled in c/c++. So for my purposes I'll settle with
> >> including "unset mouse" after "unset multiplot".
> >>
> >> Given the qualification above, it appears to me that this will  
> >> produce
> >> consistent results across different architectures, correct?
> >
> > I think we can do better than that.  Turning off mouse interaction
> > altogether is more drastic than simply turning off the extra space at
> > the bottom of the window that echoes the current coordinates.
> > What I really wanted to test was the equivalent of toggling the
> > tracking window via the 'm' hotkey.  But we don't currently have a way
> > of doing that from the command line.
> >
> > Petr Mikulik was proposing (maybe even had a patch?) to provide
> > command line equivalents for all the hotkey operations.  Perhaps he
> > has a suggestion.
> >
> 
> I agree. I have no desire to turn off the mouse interaction.
> 
> What surprised me is that the mouse interaction still works for me if  
> "unset mouse" occurs after "unset multiplot".


So now I have another question.
You are re-opening the same x11 display window for every plot.
I don't understand why you want to do that, since you could just leave
the previous window in place if the size is not supposed to change.

Be that as it may, you could try explicitly closing the previous window
before re-opening it:

    set term x11 1 size FOO,BAZ
    ...plot stuff

    set term x11 1 close 
    set term x11 1 size FOO,BAZ
    ...plot different stuff
     


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

On Dec 28, 2008, at 4:12 PM, Ethan A Merritt wrote:

> On Sunday 28 December 2008, you wrote:
>>
>> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote:
>>
>>> On Sunday 28 December 2008, you wrote:
>>>>
>>>> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote:
>>>>
>>>>> On Sunday 28 December 2008, Ben Abbott wrote:
>>>>>>
>>>>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
>>>>>>
>>>>>>> On Saturday 27 December 2008, Ben Abbott wrote:
>>>>>>>>
>>>>>>>> I've concatenated several plot streams produced by Octave to
>>>>>>>> demonstrate what
>>>>>>>> I am seeing. The file is attached.
>>>>>>>>> Just type the command below. The resulting plot should grow in
>>>>>>>>> height each
>>>>>>>> time it is plotted.
>>>>>>>
>>>>>>> I see no change in the plot window size; each plot is redrawn
>>>>>>> exactly on top
>>>>>>> of the previous one.  My machine is running
>>>>>>> x11-server-xorg-1.4.0.90
>>>>>>> kdebase-kdm-3.5.9
>>>>>>>
>>>>>>> I think that to debug this we will need to know your operating
>>>>>>> system
>>>>>>> environment, and in particular the window manager and the X- 
>>>>>>> server
>>>>>>> being used.
>>>>>>>
>>>>>>
>>>>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1.
>>>>>> If by
>>>>>> "operating system environment" you're looking for more than I  
>>>>>> gave,
>>>>>> let me know what it is you'd like to see. For more info on  
>>>>>> XQuartx
>>>>>> see
>>>>>> the link below.
>>>>>>
>>>>>> 	http://xquartz.macosforge.org/trac/wiki
>>>>>>
>>>>>> I've spent some time reducing the number of gnuplot commands  
>>>>>> needed
>>>>>> to
>>>>>> produce the problem. If the 4 lines below are placed iteratively
>>>>>> in a
>>>>>> file, the resulting window progressively grows taller (with the
>>>>>> title
>>>>>> bar being static).
>>>>>>
>>>>>> 	set terminal x11 size 560,480 position 440,106
>>>>>> 	set multiplot;
>>>>>> 	plot x
>>>>>> 	unset multiplot;
>>>>>>
>>>>>> I've attached another file for this simplified example.
>>>>>>
>>>>>> In any event, the problem appears to only exist (for me) in
>>>>>> multiplot
>>>>>> mode. I also noticed that the final window height is not always  
>>>>>> the
>>>>>> same.
>>>>>
>>>>> Could you please try adding the command "unset mouse" to the
>>>>> beginning
>>>>> of your test script, and check whether that makes any difference?
>>>>
>>>> bingo!
>>>>
>>>> When "unset mouse" precedes the first "set terminal x11 ..."  
>>>> command
>>>> the resulting plot is unaware of the mouse.
>>>>
>>>> However, when I tried ...
>>>>
>>>> 	set terminal x11 size 560,480 position 440,106
>>>> 	set multiplot;
>>>> 	plot x
>>>> 	unset multiplot;
>>>> 	unset mouse
>>>>
>>>> The tracing of the cursor still works.
>>>>
>>>> Is this behavior expected/intended? ... meaning; Are the mouse
>>>> actions
>>>> enabled when the mouse is set and the 1st "set terminal [...]"
>>>> command
>>>> is encountered? ... and that subsequent "unset mouse" commands will
>>>> not turn the mouse actions off?
>>>>
>>>> Ben
>>>>
>>>> p.s. when the mouse actions are active my x11 window extends down a
>>>> bit. My impression is that the degree to which it extends is the  
>>>> same
>>>> as the amount the window grows, I assume this was what your were
>>>> thinking?
>>>
>>> Yeah.  Not that it really explains anything.
>>>
>>> I'll make a wild guess that the problem is related to the code
>>> introduced by the comment at line 4284 of gplt_x11.c
>>>
>>> 4284:
>>> /* it seems to be impossible to distinguish between a
>>>  * resize caused by our call to XResizeWindow(), and
>>>  * resize started by the user/windowmanager; but we can
>>>  * make a good guess which can only fail if the user
>>>  * resizes the window while we're also resizing it
>>>  * ourselves: */
>>>
>>> It claims to be working around various window-manager quirks.
>>> You could try commenting out various sections of that code, or
>>> adding debug statement to keep track of which code path is being
>>> triggered. It may be that an additional test, or conditional code
>>> for Mac OSX, could bypass the problematic code path.
>>
>> I'm unskilled unskilled in c/c++. So for my purposes I'll settle with
>> including "unset mouse" after "unset multiplot".
>>
>> Given the qualification above, it appears to me that this will  
>> produce
>> consistent results across different architectures, correct?
>
> I think we can do better than that.  Turning off mouse interaction
> altogether is more drastic than simply turning off the extra space at
> the bottom of the window that echoes the current coordinates.
> What I really wanted to test was the equivalent of toggling the
> tracking window via the 'm' hotkey.  But we don't currently have a way
> of doing that from the command line.
>
> Petr Mikulik was proposing (maybe even had a patch?) to provide
> command line equivalents for all the hotkey operations.  Perhaps he
> has a suggestion.
>

I agree. I have no desire to turn off the mouse interaction.

What surprised me is that the mouse interaction still works for me if  
"unset mouse" occurs after "unset multiplot".

Ben

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 28 December 2008, you wrote:
> 
> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote:
> 
> > On Sunday 28 December 2008, you wrote:
> >>
> >> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote:
> >>
> >>> On Sunday 28 December 2008, Ben Abbott wrote:
> >>>>
> >>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
> >>>>
> >>>>> On Saturday 27 December 2008, Ben Abbott wrote:
> >>>>>>
> >>>>>> I've concatenated several plot streams produced by Octave to
> >>>>>> demonstrate what
> >>>>>> I am seeing. The file is attached.
> >>>>>>> Just type the command below. The resulting plot should grow in
> >>>>>>> height each
> >>>>>> time it is plotted.
> >>>>>
> >>>>> I see no change in the plot window size; each plot is redrawn
> >>>>> exactly on top
> >>>>> of the previous one.  My machine is running
> >>>>> x11-server-xorg-1.4.0.90
> >>>>> kdebase-kdm-3.5.9
> >>>>>
> >>>>> I think that to debug this we will need to know your operating
> >>>>> system
> >>>>> environment, and in particular the window manager and the X-server
> >>>>> being used.
> >>>>>
> >>>>
> >>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1.  
> >>>> If by
> >>>> "operating system environment" you're looking for more than I gave,
> >>>> let me know what it is you'd like to see. For more info on XQuartx
> >>>> see
> >>>> the link below.
> >>>>
> >>>> 	http://xquartz.macosforge.org/trac/wiki
> >>>>
> >>>> I've spent some time reducing the number of gnuplot commands needed
> >>>> to
> >>>> produce the problem. If the 4 lines below are placed iteratively  
> >>>> in a
> >>>> file, the resulting window progressively grows taller (with the  
> >>>> title
> >>>> bar being static).
> >>>>
> >>>> 	set terminal x11 size 560,480 position 440,106
> >>>> 	set multiplot;
> >>>> 	plot x
> >>>> 	unset multiplot;
> >>>>
> >>>> I've attached another file for this simplified example.
> >>>>
> >>>> In any event, the problem appears to only exist (for me) in  
> >>>> multiplot
> >>>> mode. I also noticed that the final window height is not always the
> >>>> same.
> >>>
> >>> Could you please try adding the command "unset mouse" to the  
> >>> beginning
> >>> of your test script, and check whether that makes any difference?
> >>
> >> bingo!
> >>
> >> When "unset mouse" precedes the first "set terminal x11 ..." command
> >> the resulting plot is unaware of the mouse.
> >>
> >> However, when I tried ...
> >>
> >> 	set terminal x11 size 560,480 position 440,106
> >> 	set multiplot;
> >> 	plot x
> >> 	unset multiplot;
> >> 	unset mouse
> >>
> >> The tracing of the cursor still works.
> >>
> >> Is this behavior expected/intended? ... meaning; Are the mouse  
> >> actions
> >> enabled when the mouse is set and the 1st "set terminal [...]"  
> >> command
> >> is encountered? ... and that subsequent "unset mouse" commands will
> >> not turn the mouse actions off?
> >>
> >> Ben
> >>
> >> p.s. when the mouse actions are active my x11 window extends down a
> >> bit. My impression is that the degree to which it extends is the same
> >> as the amount the window grows, I assume this was what your were
> >> thinking?
> >
> > Yeah.  Not that it really explains anything.
> >
> > I'll make a wild guess that the problem is related to the code
> > introduced by the comment at line 4284 of gplt_x11.c
> >
> > 4284:
> >  /* it seems to be impossible to distinguish between a
> >   * resize caused by our call to XResizeWindow(), and
> >   * resize started by the user/windowmanager; but we can
> >   * make a good guess which can only fail if the user
> >   * resizes the window while we're also resizing it
> >   * ourselves: */
> >
> > It claims to be working around various window-manager quirks.
> > You could try commenting out various sections of that code, or
> > adding debug statement to keep track of which code path is being
> > triggered. It may be that an additional test, or conditional code
> > for Mac OSX, could bypass the problematic code path.
> 
> I'm unskilled unskilled in c/c++. So for my purposes I'll settle with  
> including "unset mouse" after "unset multiplot".
> 
> Given the qualification above, it appears to me that this will produce  
> consistent results across different architectures, correct?

I think we can do better than that.  Turning off mouse interaction
altogether is more drastic than simply turning off the extra space at
the bottom of the window that echoes the current coordinates.
What I really wanted to test was the equivalent of toggling the
tracking window via the 'm' hotkey.  But we don't currently have a way
of doing that from the command line.

Petr Mikulik was proposing (maybe even had a patch?) to provide
command line equivalents for all the hotkey operations.  Perhaps he
has a suggestion.




> Ben
> 
> p.s. we dropped of the list, I assume that was intentional?

Not really.



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

On Dec 28, 2008, at 2:26 PM, Ben Abbott wrote:

>
> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote:
>
>> On Sunday 28 December 2008, Ben Abbott wrote:
>>>
>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
>>>
>>>> On Saturday 27 December 2008, Ben Abbott wrote:
>>>>>
>>>>> I've concatenated several plot streams produced by Octave to
>>>>> demonstrate what
>>>>> I am seeing. The file is attached.
>>>>>> Just type the command below. The resulting plot should grow in
>>>>>> height each
>>>>> time it is plotted.
>>>>
>>>> I see no change in the plot window size; each plot is redrawn
>>>> exactly on top
>>>> of the previous one.  My machine is running
>>>> x11-server-xorg-1.4.0.90
>>>> kdebase-kdm-3.5.9
>>>>
>>>> I think that to debug this we will need to know your operating  
>>>> system
>>>> environment, and in particular the window manager and the X-server
>>>> being used.
>>>>
>>>
>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If  
>>> by
>>> "operating system environment" you're looking for more than I gave,
>>> let me know what it is you'd like to see. For more info on XQuartx  
>>> see
>>> the link below.
>>>
>>> 	http://xquartz.macosforge.org/trac/wiki
>>>
>>> I've spent some time reducing the number of gnuplot commands  
>>> needed to
>>> produce the problem. If the 4 lines below are placed iteratively  
>>> in a
>>> file, the resulting window progressively grows taller (with the  
>>> title
>>> bar being static).
>>>
>>> 	set terminal x11 size 560,480 position 440,106
>>> 	set multiplot;
>>> 	plot x
>>> 	unset multiplot;
>>>
>>> I've attached another file for this simplified example.
>>>
>>> In any event, the problem appears to only exist (for me) in  
>>> multiplot
>>> mode. I also noticed that the final window height is not always the
>>> same.
>>
>> Could you please try adding the command "unset mouse" to the  
>> beginning
>> of your test script, and check whether that makes any difference?
>
> bingo!
>
> When "unset mouse" precedes the first "set terminal x11 ..." command  
> the resulting plot is unaware of the mouse.
>
> However, when I tried ...
>
> 	set terminal x11 size 560,480 position 440,106
> 	set multiplot;
> 	plot x
> 	unset multiplot;
> 	unset mouse
>
> The tracing of the cursor still works.
>
> Is this behavior expected/intended? ... meaning; Are the mouse  
> actions enabled when the mouse is set and the 1st "set terminal  
> [...]" command is encountered? ... and that subsequent "unset mouse"  
> commands will not turn the mouse actions off?
>
> Ben

Another quick comment. I checked with another Mac OSX user. He is  
running ...

>> OS X 10.4.11, i386, and current the X11 server is
>>
>> bash ~$ X -version
>> XFree86 Version 4.4.0 / X Window System
>> (protocol Version 11, revision 0, vendor release 6600)

So he has a different version of OSX and is running a different X- 
server. The growing window problem also existed for him and  
disappeared when "unset mouse" was added below "unset multiplot".

Ben

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote:

> On Sunday 28 December 2008, Ben Abbott wrote:
>>
>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
>>
>>> On Saturday 27 December 2008, Ben Abbott wrote:
>>>>
>>>> I've concatenated several plot streams produced by Octave to
>>>> demonstrate what
>>>> I am seeing. The file is attached.
>>>>> Just type the command below. The resulting plot should grow in
>>>>> height each
>>>> time it is plotted.
>>>
>>> I see no change in the plot window size; each plot is redrawn
>>> exactly on top
>>> of the previous one.  My machine is running
>>> x11-server-xorg-1.4.0.90
>>> kdebase-kdm-3.5.9
>>>
>>> I think that to debug this we will need to know your operating  
>>> system
>>> environment, and in particular the window manager and the X-server
>>> being used.
>>>
>>
>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If by
>> "operating system environment" you're looking for more than I gave,
>> let me know what it is you'd like to see. For more info on XQuartx  
>> see
>> the link below.
>>
>> 	http://xquartz.macosforge.org/trac/wiki
>>
>> I've spent some time reducing the number of gnuplot commands needed  
>> to
>> produce the problem. If the 4 lines below are placed iteratively in a
>> file, the resulting window progressively grows taller (with the title
>> bar being static).
>>
>> 	set terminal x11 size 560,480 position 440,106
>> 	set multiplot;
>> 	plot x
>> 	unset multiplot;
>>
>> I've attached another file for this simplified example.
>>
>> In any event, the problem appears to only exist (for me) in multiplot
>> mode. I also noticed that the final window height is not always the
>> same.
>
> Could you please try adding the command "unset mouse" to the beginning
> of your test script, and check whether that makes any difference?

bingo!

When "unset mouse" precedes the first "set terminal x11 ..." command  
the resulting plot is unaware of the mouse.

However, when I tried ...

	set terminal x11 size 560,480 position 440,106
	set multiplot;
	plot x
	unset multiplot;
	unset mouse

The tracing of the cursor still works.

Is this behavior expected/intended? ... meaning; Are the mouse actions  
enabled when the mouse is set and the 1st "set terminal [...]" command  
is encountered? ... and that subsequent "unset mouse" commands will  
not turn the mouse actions off?

Ben

p.s. when the mouse actions are active my x11 window extends down a  
bit. My impression is that the degree to which it extends is the same  
as the amount the window grows, I assume this was what your were  
thinking?


Ben

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 28 December 2008, Ben Abbott wrote:
> 
> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
> 
> > On Saturday 27 December 2008, Ben Abbott wrote:
> >>
> >> I've concatenated several plot streams produced by Octave to  
> >> demonstrate what
> >> I am seeing. The file is attached.
> >>> Just type the command below. The resulting plot should grow in  
> >>> height each
> >> time it is plotted.
> >
> > I see no change in the plot window size; each plot is redrawn  
> > exactly on top
> > of the previous one.  My machine is running
> >  x11-server-xorg-1.4.0.90
> >  kdebase-kdm-3.5.9
> >
> > I think that to debug this we will need to know your operating system
> > environment, and in particular the window manager and the X-server  
> > being used.
> >
> 
> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If by  
> "operating system environment" you're looking for more than I gave,  
> let me know what it is you'd like to see. For more info on XQuartx see  
> the link below.
> 
> 	http://xquartz.macosforge.org/trac/wiki
> 
> I've spent some time reducing the number of gnuplot commands needed to  
> produce the problem. If the 4 lines below are placed iteratively in a  
> file, the resulting window progressively grows taller (with the title  
> bar being static).
> 
> 	set terminal x11 size 560,480 position 440,106
> 	set multiplot;
> 	plot x
> 	unset multiplot;
> 
> I've attached another file for this simplified example.
> 
> In any event, the problem appears to only exist (for me) in multiplot  
> mode. I also noticed that the final window height is not always the  
> same.

Could you please try adding the command "unset mouse" to the beginning
of your test script, and check whether that makes any difference?




-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:

> On Saturday 27 December 2008, Ben Abbott wrote:
>>
>> I've concatenated several plot streams produced by Octave to  
>> demonstrate what
>> I am seeing. The file is attached.
>>> Just type the command below. The resulting plot should grow in  
>>> height each
>> time it is plotted.
>
> I see no change in the plot window size; each plot is redrawn  
> exactly on top
> of the previous one.  My machine is running
>  x11-server-xorg-1.4.0.90
>  kdebase-kdm-3.5.9
>
> I think that to debug this we will need to know your operating system
> environment, and in particular the window manager and the X-server  
> being used.
>

I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If by  
"operating system environment" you're looking for more than I gave,  
let me know what it is you'd like to see. For more info on XQuartx see  
the link below.

	http://xquartz.macosforge.org/trac/wiki

I've spent some time reducing the number of gnuplot commands needed to  
produce the problem. If the 4 lines below are placed iteratively in a  
file, the resulting window progressively grows taller (with the title  
bar being static).

	set terminal x11 size 560,480 position 440,106
	set multiplot;
	plot x
	unset multiplot;

I've attached another file for this simplified example.

In any event, the problem appears to only exist (for me) in multiplot  
mode. I also noticed that the final window height is not always the  
same.

Ben

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 27 December 2008, Ben Abbott wrote:
> 
> I've concatenated several plot streams produced by Octave to demonstrate what
> I am seeing. The file is attached.
> > Just type the command below. The resulting plot should grow in height each 
> time it is plotted.

I see no change in the plot window size; each plot is redrawn exactly on top
of the previous one.  My machine is running
  x11-server-xorg-1.4.0.90
  kdebase-kdm-3.5.9

I think that to debug this we will need to know your operating system 
environment, and in particular the window manager and the X-server being used.


 
> $ gnuplot -persist growing_plot.gp
> 
> http://www.nabble.com/file/p21190150/growing_plot.gp growing_plot.gp 
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

I've concatenated several plot streams produced by Octave to demonstrate what
I am seeing. The file is attached.

Just type the command below. The resulting plot should grow in height each
time it is plotted.

$ gnuplot -persist growing_plot.gp

http://www.nabble.com/file/p21190150/growing_plot.gp growing_plot.gp 

-- 
View this message in context: http://www.nabble.com/problem-with-%22set-x11-%7Bsize-WW%2CHH%7D-%7Bposition-XX%2CYY%7D%22-tp21190071p21190150.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

Recently a change was committed that allows the x11 terminal to have  
its size and position specified.

I've attempted to use this new feature from Octave.

I've modified a local version of Octave's gnuplot_drawnow.m to take  
advantage of these features. The first time a plot is drawn it works  
correctly. When I place a loop around a plot command, the plot grows  
progressively taller. It appears the each plot produces a window which  
is taller by an amount approximately equal to 10 pixels.

Thus, figure(1) below is about 100 pixels taller than figure(2)

	figure(1)
	clf
	for n=1:11
		plot(1:10)
		drawnow
	endfor

	figure(2)
	clf
	plot(1:10)

Iteratively typing plot(1:10) at octave's command does not produce the  
problem.

I've attached a simple changeset which can be applied to Octave's  
developer's sources to duplicate this problem.

I'm eager to find a solution so if there is anything I can try to  
isolate the problem, let me know.

Ben

Re: Tweak for interactive SVGs?

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 27 December 2008, James R. Van Zandt wrote:
> 
> Peter <pl...@pi...> writes:
> 
> > In the mean time it would be good to start defining what functionality
> > to add and how to integrate this into gnuplot command structure.
> >
> > I would strongly recommend a well thought out and extensible structure
> > because the possibilities that this kind of technique opens up are vast.
> > It should be anticipated from the outset that this will develop over
> > time to be a very full featured extension quite likely with the need to
> > user definable elements.
> 
> I think these would be useful functions for a selected curve:
> 
>  - Toggle visibility (as Bill demonstrated).
> 
>  - Move to front/back.
> 
>  - Dim (partially desaturate, or just turn light gray) / restore.  
> 
>  - Highlight (move to front, and dim all the other curves) / restore.
> 
>  - If X2 or Y2 axes are in use, then when you select a curve, it would
>    be nice to have the corresponding axes automatically highlighted.

What sort of user interface would this functionality use?

Would it be possible to implement popup menus for all the interactive
terminals?  
svg - easy if you have already commited to using jscript or the like.
wxt - there is an extension that allow this, but it is very crude
x11 - not without pulling in some additional toolkit layer
win - no idea

Or perhaps we could add a clickable icon to each key entry?
1st click toggles off, 2nd click brings it back at dim/grey,
3rd click highlights, 4th click returns it to the original state



> I would also like a way to select a data point on the graph and
> display information about it.  In particular:
> 
>  - The X, Y (Z, T, U, V) data value, with full precision (not
>    transformed to integer screen coordinates then transformed back).
>    Also DX and DY for errorbars graphs.
> 
>  - Where it came from (file name, line, index, line within index,
>    etc.).  Useful for tracking down an outlier.
> 
> If there are several data points very close together (say, within an
> eight pixel radius), I would like a way to cycle among them.
> 
> 
>                 - Jim Van Zandt

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Supporting '#' in set format

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 27 December 2008, Allin Cottrell wrote:
> On Sat, 27 Dec 2008, Allin Cottrell wrote:
> 
> > Please find attached a little patch to util.c which supports
> > the '#' flag for gprintf, for formats where it is supported by
> > C's printf.

Added to CVS.

NB: that test can be done more economically as

+       if (got_hash && (format == strpbrk(format,"oeEfFgG"))) {
+          reset_numeric_locale();
+          int_error(NO_CARET, "Bad format character");
+       }


-- 
Ethan A Merritt

Re: Tweak for interactive SVGs?

[James R. V. Z. <jr...@co...>]

Peter <pl...@pi...> writes:

> In the mean time it would be good to start defining what functionality
> to add and how to integrate this into gnuplot command structure.
>
> I would strongly recommend a well thought out and extensible structure
> because the possibilities that this kind of technique opens up are vast.
> It should be anticipated from the outset that this will develop over
> time to be a very full featured extension quite likely with the need to
> user definable elements.

I think these would be useful functions for a selected curve:

 - Toggle visibility (as Bill demonstrated).

 - Move to front/back.

 - Dim (partially desaturate, or just turn light gray) / restore.  

 - Highlight (move to front, and dim all the other curves) / restore.

 - If X2 or Y2 axes are in use, then when you select a curve, it would
   be nice to have the corresponding axes automatically highlighted.

I would also like a way to select a data point on the graph and
display information about it.  In particular:

 - The X, Y (Z, T, U, V) data value, with full precision (not
   transformed to integer screen coordinates then transformed back).
   Also DX and DY for errorbars graphs.

 - Where it came from (file name, line, index, line within index,
   etc.).  Useful for tracking down an outlier.

If there are several data points very close together (say, within an
eight pixel radius), I would like a way to cycle among them.


                - Jim Van Zandt

Re: Supporting '#' in set format

[Allin C. <cot...@wf...>]

On Sat, 27 Dec 2008, Allin Cottrell wrote:

> Please find attached a little patch to util.c which supports
> the '#' flag for gprintf, for formats where it is supported by
> C's printf.

Oof, patch came complete with bug.  This should be better.

Allin Cottrell

Supporting '#' in set format

[Allin C. <cot...@wf...>]

Please find attached a little patch to util.c which supports
the '#' flag for gprintf, for formats where it is supported by
C's printf.

Allin Cottrell

Re: current cvs broke?

[Allin C. <cot...@wf...>]

On Fri, 26 Dec 2008, Ethan A Merritt wrote:

> If it were up to me, I would drop the texinfo support altogether.
> It's got to be the world's most cumbersome and worst-designed
> documentation system.

Whatever merits it may have had in its day, texinfo seem seriously
obsolete.

Allin Cottrell

Re: TikZ terminal

[Ethan A M. <merritt@u.washington.edu>]

On Friday 26 December 2008, Peter Hedwig wrote:
> Am Dienstag, 23. Dezember 2008 schrieb Ethan A Merritt:
> > On Monday 22 December 2008, Mojca Miklavec wrote:
> > > Hello,
> > >
> > > here are a few suggestions for the new TikZ terminal:
> > >
> > > 1.) I would rename gnuplot.lua into tikz.lua or gnuplot-tikz.lua. The
> > > terminal lua is generic, but gnuplot.lua is TikZ-specific.
> 
> Yes.
> 
> > > 2.) I would require calling
> > >    set term tikz
> > > or
> > >    set term lua tikz
> > > and not
> > >    set term lua
> > >
> > > Lua is a generic driver and would not tell anything to the user that
> > > wants to plot something in TeX.
> >
> > How about using a scheme similar to the cairo-based terminals
> > pdfcairo and pngcairo.  The current terminal would have the full name
> > tikzlua, and the short form "tikz" would work unless/until someone
> > writes a pure tikz terminal that doesn't use lua (just as the old
> > pdf and png terminals don't use cairo).
> 
> The downside is that we need to touch lua.trm for every new backend script 
> then.  

Are you thinking this will be common?  It's not as if people have been
contributing new drivers every couple of weeks...

> What about "luatikz"?  This would call the Lua terminal for every  
> luaXY, no? Then the terminal can look for a script named gnuplot-XY.lua.

Other than the worry that my fingers will type "lunatics" instead,
it's OK with me.

> > > If one writes metapost.lua then one could for example call
> > >     set term lua metapost
> > > to invoke that file.

That would also be OK.

> The infrastructure for this is in, it just needs to return more values...
> 
> > > 4.) Help should also be returned via
> > >    help term tikz
> > >
> > > Now set term lua help returns something useful, but help term tikz
> > > should be more informative as well.
> 
> This could turn out as a real problem if we don't move the help text to 
> lua.trm.  And this would spoil the idea of keeping the terminal and the script 
> separated.
> 
> > > 5.) Maybe there could be
> > >    gnuplot.lua
> > > that has a list of available terminals, for example a list containing
> > > "tikz" terminal with both terminal name and filename that needs to be
> > > included to make that terminal work properly.
> 
> I think this is also related to the decision if we keep the terminal and the 
> script separated.
> 
> While I would like to keep them separated, I don't know how to fix the help 
> system then :-(

Maybe the build system could run the lua script and cat the output into
"allterm.h"?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Tweak for interactive SVGs? ToggleVisibility

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

Ethan A Merritt wrote:
> On Thursday 25 December 2008, pl...@pi... wrote:
>> Hi,
>>
>> Bill never got a reply to his question of whether a patch to add
>> ToggleVisibility to gnuplot would be likely to get accepted. I would
>> like to reiterate that question.
> 
> I am very interested in seeing the SVG terminal evolve into an
> interactive client-side terminal.  So yes, ideas and actual patches
> are welcome.
> 
> But I'd like there to be some sort of coherent development plan.
> It should balance at least two considerations:
> 
> 1) Features that can be implemented for more than one terminal are 
>    prefered.  If toggling the plots on/off interactively is a 
>    useful thing to do, why should we limit it to SVG?
> 
> 2) If at all possible, multiple features added to SVG (or any other
>    terminal) should share a common syntax and parallel implementation.
>    We can hope that makes them easier to remember for the users and
>    easier to maintain for the developers.
> 
> So it's great if you want to block out an SVG implementation, as you
> do below, but let's also see some suggestions for how this is 
> specified by the user in a gnuplot command, and especially let's 
> brainstorm whether it can also be implemented for x11, windows,
> aquaterm, wxt. Maybe even pdf? fig? 
> 
I had deliberately stayed away from proposing command syntax since I am
not too familiar with how the core team see it being organised. I did
ask for some input on that aspect.

> And, as I requested before, please think about how this addition
> fits in with the idea of adding hyperlinks (SourceForge patch #2172587).
> Is it best to add lots of command line options, but hide the details
> from the user, as in:
>     set term svg href=(plots,labels,foo)
> or is it better to let the user pass an opaque chunk of text for
> inclusion in the output file, perhaps gaining far more flexibility 
> but requiring detailed implementation knowledge on the part of the user?
>     set term svg plot="some opaque per-plot svg fragment" \
>                  key = "some opaque per-key svg fragment" \
>                  label="some opaque per-label svg fragment"
>                  script="script to be included in output"
> 
> My inclination is that the latter approach is only tolerable for
> svg-specific features.  Any feature that is shared by multiple
> terminals should stand on its own, not requiring device-specific
> commands.
> 

I had imagined something that fits both approaches. I prefer the second
syntax and its flexibility but the simple "opaque" solution can be
compatible by providing the functionality in the form of scripts
included with gnpulot in a predefined location and added into the svg
when plotting.

set term svg plotToggle="some transparent per-plot <script> fragment"

The function could be turned "on" or "off" or substituded by a user
script with this kind of syntax.

set term svg plotToggle="on"   // default = off ?
set term svg plotToggle="custom-script.js"


The toggle feature could clearly be applied to some other terminals as
well but I think because of the DOM / JS interaction SVG will offer a
whole world of dynamic content and interaction that will not be possible
on other terms.

The detail of svg implementation , even in the case of features
available in wxt etc will most likely come from including a javaScript
in the xml or via xlink. I was looking at including such source files in
a directory like the PS files : /usr/local/gnuplot/4.3/javaScript

Maybe you could save me some time by giving me a quick hint at where to
modify to create such a dir?

best regards, Peter.

Re: Tweak for interactive SVGs? ToggleVisibility

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 25 December 2008, pl...@pi... wrote:
> Hi,
> 
> Bill never got a reply to his question of whether a patch to add
> ToggleVisibility to gnuplot would be likely to get accepted. I would
> like to reiterate that question.

I am very interested in seeing the SVG terminal evolve into an
interactive client-side terminal.  So yes, ideas and actual patches
are welcome.

But I'd like there to be some sort of coherent development plan.
It should balance at least two considerations:

1) Features that can be implemented for more than one terminal are 
   prefered.  If toggling the plots on/off interactively is a 
   useful thing to do, why should we limit it to SVG?

2) If at all possible, multiple features added to SVG (or any other
   terminal) should share a common syntax and parallel implementation.
   We can hope that makes them easier to remember for the users and
   easier to maintain for the developers.

So it's great if you want to block out an SVG implementation, as you
do below, but let's also see some suggestions for how this is 
specified by the user in a gnuplot command, and especially let's 
brainstorm whether it can also be implemented for x11, windows,
aquaterm, wxt. Maybe even pdf? fig? 

And, as I requested before, please think about how this addition
fits in with the idea of adding hyperlinks (SourceForge patch #2172587).
Is it best to add lots of command line options, but hide the details
from the user, as in:
    set term svg href=(plots,labels,foo)
or is it better to let the user pass an opaque chunk of text for
inclusion in the output file, perhaps gaining far more flexibility 
but requiring detailed implementation knowledge on the part of the user?
    set term svg plot="some opaque per-plot svg fragment" \
                 key = "some opaque per-key svg fragment" \
                 label="some opaque per-label svg fragment"
                 script="script to be included in output"

My inclination is that the latter approach is only tolerable for
svg-specific features.  Any feature that is shared by multiple
terminals should stand on its own, not requiring device-specific
commands.


> The changes to svg output would be fairly trivial.
> 
> 1/ separte line sample form the <path> of the plot itself
> 2/ add some id="..." identifiers to output. This would actually be a
> good idea anyway to enable future expansion of functionality (and
> readability of the svg markup: try locating the grid output by scanning
> the current output).
> 
> eg <path id="line1" d=' ....'></path>
>    <path id="line1_sample" d=' ....'></path>
> 
> 3/ add an onclick event to the legend texts
> <text  onclick='toggleVisibility(evt,"line1")'>line1 legend</text>
> 
> 4/ add a short <script >  [CDATA[ .....</script> to the top of the svg file.
> 
> 5/ someone will have to come up with a spec for adding this to the
> command syntax.
> 
> I really like this feature and it would be a good first step in adding
> interactivity to gnuplot's svg output.
> 
> What are the chances of it getting accepted?
> 
> TIA,
> 
> Peter.


-- 
Ethan A Merritt

Re: current cvs broke?

[Ethan A M. <merritt@u.washington.edu>]

On Friday 26 December 2008, pl...@pi... wrote:
> Hi,
> 
> I just pulled a clean cvs and it fails at "make install"
> 
> 
> make[1]: Leaving directory `/svn/gnuplot/src'
> Making install in docs
> make[1]: Entering directory `/svn/gnuplot/docs'
> ../mkinstalldirs /usr/local/share/gnuplot/4.3
> /usr/bin/install -c -m 644 gnuplot.gih
> /usr/local/share/gnuplot/4.3/gnuplot.gih
> Creating texinfo
> Symbol's value as variable is void: load
> make[1]: *** [gnuplot.texi] Error 255
> make[1]: Leaving directory `/svn/gnuplot/docs'
> make: *** [install-recursive] Error 1

For reasons that we have never pinned down, some people have trouble
regenerating the gnuplot.texi file from gnuplot.doc.  That is the reason
a pre-built version is included in the cvs repository and in the 
distribution, even though it is a derived file.   But it doesn't get
updated in cvs after every single change to gnuplot.doc.

Anyhow, your simplest fix is to do "touch gnuplot.texi" before
issuing the "make" command.  That will cause it to use the current
version rather than trying to rebuild it from source.  I'll update
the copy in cvs the next time I am working on it.

If it were up to me, I would drop the texinfo support altogether.
It's got to be the world's most cumbersome and worst-designed
documentation system.


> BTW , INSTALL instructions for Unix bases system says just run
> configure. 

The INSTALL file contains instructions relevant to people who
receive it as part of the distribution package.  But you are building
directly from the CVS source; that is not the process it describes.

> This does not exist! As a wild guess I ran ./prepare so I 
> dont know if that is correct. Why are there no valid installation
> instructions included with the source code?

You can find several sets of instructions on SourceForge, which is the
same place you must have obtained the CVS source. 

   http://gnuplot.sourceforge.net/development/index.html

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

current cvs broke?

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

Hi,

I just pulled a clean cvs and it fails at "make install"


make[1]: Leaving directory `/svn/gnuplot/src'
Making install in docs
make[1]: Entering directory `/svn/gnuplot/docs'
../mkinstalldirs /usr/local/share/gnuplot/4.3
/usr/bin/install -c -m 644 gnuplot.gih
/usr/local/share/gnuplot/4.3/gnuplot.gih
Creating texinfo
Symbol's value as variable is void: load
make[1]: *** [gnuplot.texi] Error 255
make[1]: Leaving directory `/svn/gnuplot/docs'
make: *** [install-recursive] Error 1


command sequence was this:

  636  ./prepare
  637  CFLAGS="-O2" ; ./configure --prefix="/usr/local" --without-tutorial
  638  make
  639  make install


BTW , INSTALL instructions for Unix bases system says just run
configure. This does not exist! As a wild guess I ran ./prepare so I
dont know if that is correct. Why are there no valid installation
instructions included with the source code?

thanks , Peter.

Re: TikZ terminal

[Peter H. <pe...@af...>]

Am Dienstag, 23. Dezember 2008 schrieb Ethan A Merritt:
> On Monday 22 December 2008, Mojca Miklavec wrote:
> > Hello,
> >
> > here are a few suggestions for the new TikZ terminal:
> >
> > 1.) I would rename gnuplot.lua into tikz.lua or gnuplot-tikz.lua. The
> > terminal lua is generic, but gnuplot.lua is TikZ-specific.

Yes.

> > 2.) I would require calling
> >    set term tikz
> > or
> >    set term lua tikz
> > and not
> >    set term lua
> >
> > Lua is a generic driver and would not tell anything to the user that
> > wants to plot something in TeX.
>
> How about using a scheme similar to the cairo-based terminals
> pdfcairo and pngcairo.  The current terminal would have the full name
> tikzlua, and the short form "tikz" would work unless/until someone
> writes a pure tikz terminal that doesn't use lua (just as the old
> pdf and png terminals don't use cairo).

The downside is that we need to touch lua.trm for every new backend script 
then.  What about "luatikz"?  This would call the Lua terminal for every 
luaXY, no? Then the terminal can look for a script named gnuplot-XY.lua.

> > If one writes metapost.lua then one could for example call
> >     set term lua metapost
> > to invoke that file.
> >
> > 3.) I agree that the terminal should return a list of values chosen
> > for the terminal

The infrastructure for this is in, it just needs to return more values...

> > 4.) Help should also be returned via
> >    help term tikz
> >
> > Now set term lua help returns something useful, but help term tikz
> > should be more informative as well.

This could turn out as a real problem if we don't move the help text to 
lua.trm.  And this would spoil the idea of keeping the terminal and the script 
separated.

> > 5.) Maybe there could be
> >    gnuplot.lua
> > that has a list of available terminals, for example a list containing
> > "tikz" terminal with both terminal name and filename that needs to be
> > included to make that terminal work properly.

I think this is also related to the decision if we keep the terminal and the 
script separated.

While I would like to keep them separated, I don't know how to fix the help 
system then :-(

-Peter

Re: Tweak for interactive SVGs? ToggleVisibility

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

Hi,

Bill never got a reply to his question of whether a patch to add
ToggleVisibility to gnuplot would be likely to get accepted. I would
like to reiterate that question.

The changes to svg output would be fairly trivial.

1/ separte line sample form the <path> of the plot itself
2/ add some id="..." identifiers to output. This would actually be a
good idea anyway to enable future expansion of functionality (and
readability of the svg markup: try locating the grid output by scanning
the current output).

eg <path id="line1" d=' ....'></path>
   <path id="line1_sample" d=' ....'></path>

3/ add an onclick event to the legend texts
<text  onclick='toggleVisibility(evt,"line1")'>line1 legend</text>

4/ add a short <script >  [CDATA[ .....</script> to the top of the svg file.

5/ someone will have to come up with a spec for adding this to the
command syntax.

I really like this feature and it would be a good first step in adding
interactivity to gnuplot's svg output.

What are the chances of it getting accepted?

TIA,

Peter.

Re: Tweak for interactive SVGs : coordinate display

[<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.
> 

Hi,

I'll split this subject from the original thread to distinguish
discussions of coordinate display from Bill's line ToggleVisibility
proposal.


I had a closer look at mouse events and coordinates. As I originally
suspected it gets rapidly bogged down in viewer incompatibilities,
mainly the badly non-standard Abobe plugin for IE. (I just love broken
closed source software!).

Even if restricted to reasonably well written viewers like Opera and
Firefox3 it is a non trivial exercise that involves quite a bit of
javascript to take account of viewports, scrolling etc., and finally the
 accuracy of the output is compromised by the integer resolution of
mouse event coordinates.

There may be a workaround for this latter problem by defining the svg
larger and then zooming down (??).

Much of the basics can be sourced from these sites though further work
will be needed , the tooltip example produces some anomalies and
ViewBox.js comments note some limitations.


http://www.carto.net/papers/svg/gui/tooltips/
http://www.carto.net/papers/svg/resources/mapApp.js
http://www.kevlindev.com/gui/utilities/viewbox/ViewBox.js

regards, Peter.