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

Re: svg : gnuplot_plot_1

[Christoph B. <us...@be...>]

On 21.10.2011 07:43, Ethan Merritt wrote:
>
>> The 'title' option sets the svg<title>  element that is displayed by
>> some svg viewers in the title bar. It is not visible in the plot itself.
>> If not supplied it will be the same as 'js_id' value.
>
> This isn't quite correct either, at least for me running firefox here.
> Each plot has a title, and it pops up in a little box whenever the
> mouse is over that plot.   As you point out, the title of the first
> plot also is displayed in the top window bar.  But I think that may
> be a firefox bug/idiosyncracy.  Opera and Konqueror display the
> filename instead.  I don't mind adding something to make firefox
> display a different title, but so far I have not figured out how :-(

I guess, the problem is, that according to the standard it is up to the 
viewer to decide how to handle the 'title' elements:
<http://www.w3.org/TR/2000/CR-SVG-20001102/struct.html#DescriptionAndTitleElements>

Firefox seems to show the first element in the title bar, regardless of 
where it was specified (the plot titles are inside groups), but Opera 
uses only a title element which is placed in the top level of the 
document structure:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<svg width="200" height="200"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink">
   <title>The SVG title</title>
   <rect x="5" y="5" width="190" height="190" />
</svg>

So, writing the <title> next to the <desc> works fine.

Christoph

Re: svg : gnuplot_plot_1

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

On Thursday, 20 October 2011, pl...@pi... wrote:
> The 'js_id' option is used by the interactive mouse features and must be 
> a valid javascript variable name. In short, this means it cannot 
> contains certain characters like spaces and punctuation marks. An error 
> will be produced when the graph is plotted if this is not a valid name. 
> If not specified it will be 'gnuplot_plot_n' , where n is 1 for a simple 
> plot but may be greater than one in the case of multiplot output.

Just FYI, that isn't quite correct.  "n" increases with each plot in the
graph.  So if you say 
   plot sin(x),cos(x),'foo.dat','baz.dat'
these are plot_1, plot_2, plot_3, and plot_4.

Multiplot is a whole separate issue, currently broken.
I suppose we will have to come up with a revise scheme to handle it.

> The 'title' option sets the svg <title> element that is displayed by 
> some svg viewers in the title bar. It is not visible in the plot itself. 
> If not supplied it will be the same as 'js_id' value.

This isn't quite correct either, at least for me running firefox here.
Each plot has a title, and it pops up in a little box whenever the 
mouse is over that plot.   As you point out, the title of the first
plot also is displayed in the top window bar.  But I think that may
be a firefox bug/idiosyncracy.  Opera and Konqueror display the 
filename instead.  I don't mind adding something to make firefox
display a different title, but so far I have not figured out how :-(

	Ethan

Re: svg : gnuplot_plot_1

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 20 October 2011, pl...@pi... wrote:
> In this context the title is quite visible and underlines look a bit 
> untidy. Hence my interest in getting a more presentable title displayed 
> by the browser.

So I just tried to implement this, and I can't get it to work.
Maybe your version of Firefox is different?

When I open the svg file in Firefox the behaviour of the individual
<title = "name_plot_1"> elements works as intended:  when the mouse
is over the plot with that title, a little box pops up displaying
the title.  

Separate from that, the title of the first plot in the file is also
displayed in the top border window decoration, which is I think
what you are talking about, right?  (I'm running KDE with a theme
that has this; I don't know what happens if you're running a desktop
or theme that doesn't place an extra decoration bar on the top).

But when I tried adding an additional title in various svg elements
near the top of the file to see if that replaced the one on the
window border - it didn't. So at this moment I don't know how to do it.  
If you have a sample file produced by some other program that behaves
the way you like, why don't you send it to me and I'll see if I can
figure out how they did it.

	cheers,

		Ethan

Re: svg : gnuplot_plot_1

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

On 10/21/11 02:59, Ethan A Merritt wrote:
> On Thursday, October 20, 2011 03:34:51 pm pl...@pi... wrote:
>
>> I really don't see why the needs of the demo script should have any
>> impact on how the program functions.
>
> My point was that I really don't know how the "typical user" operates.
> The only experience I have to work from is my own, and my use has been
> script-driven generation of web pages.  I only mentioned the demo set
> because that is an example everyone has access to, not because it has
> any particular importance on its own.
>
>> The svg file is an automonmous file format , I would have thought the
>> viewing it in an svg viewer would have been the reference condition.
>
> Maybe for some users it is.  So far everyone I've heard from has been
> generating svg plots explicitly to embed them in some larger document.
>
My initial use of svg was just that , embedding svg on an embedded system.

I have recently found that the combination of zoom, mouse coords and 
visibility toggle in svg makes it more useful than wxt for close 
inspection of detailed graphs.

I have taken to transmitting plots as svg by email and recommending 
Firefox as viewer.
That way the other end benefits from all these features as well. That is 
a huge plus and I thank you for all your work in adding svg output.

In this context the title is quite visible and underlines look a bit 
untidy. Hence my interest in getting a more presentable title displayed 
by the browser.

>> Why would anyone want to set the id , js_id or jsname at all ?
>
> I have been trying to explain that.  If you are creating dynamic content
> from a script, the script needs to create an svg (or HTML5 canvas) plot with
> named tags, and then also create javascript code that acts on those named
> tags.  So it needs to specify a non-redundant name for each plot, and that
> name must be legal in both xml and javascript.  If gnuplot changes the
> requested name to something else, it breaks the connection between the
> plot and the associated javascript.
>
OK , you clearly see a need for it and having that possibility cannot be 
bad.

I would imagine that someone working at that level must be aware of the 
language requirements so probably the most useful thing would be for 
this to be clearly documented.

It seems at the moment all the user has on this is the entry in the 
syntax definition:
  {name <plotname>} , so a short para in the detailed description would 
be valuable.

To avoid confusion in introducing more terms I suggest "name" becomes 
"title" and sets the svg title. The svg id , as you suggest, could be 
done by a new argument. I would suggest "id" or js_id" if you want to 
underline the javascript link here.

I'll anticipate your asking me to suggest what that text might be:

 >>

The 'js_id' option is used by the interactive mouse features and must be 
a valid javascript variable name. In short, this means it cannot 
contains certain characters like spaces and punctuation marks. An error 
will be produced when the graph is plotted if this is not a valid name. 
If not specified it will be 'gnuplot_plot_n' , where n is 1 for a simple 
plot but may be greater than one in the case of multiplot output.

The 'title' option sets the svg <title> element that is displayed by 
some svg viewers in the title bar. It is not visible in the plot itself. 
If not supplied it will be the same as 'js_id' value.

 >>

>>>> I don't see right away where you could have multiple plots without an
>>>> HTML wrapper
>>
>>> Christoph points out that the current scheme doesn't deal well with
>>> multiplot mode.  All the plots in a multiplot get the same name.
>>
>> See my reply to Christoph, they don't get the same value, one is wrong.
>> I found what looks like a simple slip up in the source.
>
> I think you are misinterpreting something.  Try running "multiplt.dem"
> in the demo set.  Each of the 4 graphs in the resulting svg file contains
> plots named "multiplt_plot_1", "multiplot_plot_2", and so on.
> So we end up with 4 copies of each, which is a problem.
>
> The "gnuplot_canvas" identifier is attached to the top-level group that
> bounds the whole document so that the mousing code can find it.
> Its name is purely arbitrary and has nothing to do with any of the
> individual plots.
>
> 	Ethan
>
Sorry, I thought I had spotted a simple slip up. I have not looked 
closely at this , I'll shut up on this issue. ;)

Thanks again for svg mouse interactivity. This makes svg an ideal format 
for lab work and for collaborating with others remotely where they get 
the same (better) interactivity than I am used to in wxt.


regards, Peter.

Re: svg : gnuplot_plot_1

[Ethan A M. <sf...@us...>]

On Thursday, October 20, 2011 03:34:51 pm pl...@pi... wrote:
 
> I really don't see why the needs of the demo script should have any 
> impact on how the program functions.

My point was that I really don't know how the "typical user" operates.
The only experience I have to work from is my own, and my use has been
script-driven generation of web pages.  I only mentioned the demo set
because that is an example everyone has access to, not because it has
any particular importance on its own.

> The svg file is an automonmous file format , I would have thought the 
> viewing it in an svg viewer would have been the reference condition.

Maybe for some users it is.  So far everyone I've heard from has been
generating svg plots explicitly to embed them in some larger document.

> Why would anyone want to set the id , js_id or jsname at all ?

I have been trying to explain that.  If you are creating dynamic content
from a script, the script needs to create an svg (or HTML5 canvas) plot with
named tags, and then also create javascript code that acts on those named
tags.  So it needs to specify a non-redundant name for each plot, and that
name must be legal in both xml and javascript.  If gnuplot changes the
requested name to something else, it breaks the connection between the
plot and the associated javascript.

> >> I don't see right away where you could have multiple plots without an
> >> HTML wrapper
>
> > Christoph points out that the current scheme doesn't deal well with
> > multiplot mode.  All the plots in a multiplot get the same name.
> 
> See my reply to Christoph, they don't get the same value, one is wrong. 
> I found what looks like a simple slip up in the source.

I think you are misinterpreting something.  Try running "multiplt.dem"
in the demo set.  Each of the 4 graphs in the resulting svg file contains
plots named "multiplt_plot_1", "multiplot_plot_2", and so on.
So we end up with 4 copies of each, which is a problem.

The "gnuplot_canvas" identifier is attached to the top-level group that
bounds the whole document so that the mousing code can find it.  
Its name is purely arbitrary and has nothing to do with any of the
individual plots.

	Ethan

Re: svg : gnuplot_plot_1

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

On 10/20/11 17:47, sfeam (Ethan Merritt) wrote:
> On Thursday, 20 October 2011, pl...@pi... wrote:
>> On 10/20/11 02:17, Ethan A Merritt wrote:
>> How about:
>>
>> svg name is a javascript variable and has restrictions (eg no spaces or
>> dots '.' ).
>
> If you want to hide the technical details from the user, wouldn't it
> be better to avoid mention of javascript and simply say:
>
>     "name" must not contain spaces or punctuation
>
I was trying ot cover both ends, giving a simple bottom line and the 
reason.
What you suggest is also valid and probably sufficient.

In any case I think that would be preferable to the current error msg 
that is too obscure from a user's point of view.


>> Of course , parsing the name as I suggested would probably prevent the
>> user needing to know what a valid js variable name is. He probably
>> should not need this level of knowledge to plot a graph.
>>>>> Would it be
>>>>> better to substitute spaces with underscores internally when composing
>>>>> the id and allow spaces in name, and hence the visible title?
>
> It depends on who you expect to be the typical user.
> I have used svg mostly in the context of  making web pages, and most
> of my experience came from adapting the automated script for
> generating gnuplot's collection of on-line demos.  Because it's an
> automated script, it depends on the "name" being used exactly as
> specified.  If the program were to do any character substitution
> then the corresponding javascript generated by the script would
> not find a plot element with the appropriate name.
This sounds a little like putting the cart before the horse. Gnuplot 
should function in the way that is most useful to the user , the demo 
page script should fall in behind.

I really don't see why the needs of the demo script should have any 
impact on how the program functions.

Since you maintain both (and thank you on both counts) this may have 
seemed logical at the time. Perhaps this discussion will help refocus on 
the primary function of producing graphs from an end user perspective.

Whatever road this takes, it needs to be clearly documented. At present 
name is there as an option but there is no explanation of what it does 
(be it id or title or both , it is not documented).
>

>> ... the title which is visible in the viewer. In the case of firefox
>> it appears in the tab title and the currently displayed tab's title is
>> also shown in FF window title bar.
>
> Aha.  But this only seems to be relevant if you point the browser
> directly at the svg file itself, rather than at an html/xml document that
> contains the svg file.  I hadn't noticed, because I don't
> normally use the browser that way.
>
The svg file is an automonmous file format , I would have thought the 
viewing it in an svg viewer would have been the reference condition. I 
would not assume that a jpeg was to be viewed embedded in HTML either, 
even if that is often the case.


> I have no objection to adding a "title" keyword, that defaults to the
> bare plot name if not provided.  For that matter, perhaps the keyword
> "name" should be "jsname"?  Anyhow, at some point it would be nice to
> add a new section to the documentation dealing with generation of web
> pages. The concerns with javascript namespace, etc, are also relevant
> to the HTML5 canvas terminal.

Since this is up for suggestions , why mix up terminology? It seems to 
me that someone wishing to give it a "name" is wishing to attribute 
something human readable , this probably is best called "title" as it is 
in SVG std, rather than inventing yet another term for the same thing.

Why would anyone want to set the id , js_id or jsname at all ?
May be it is not a bad idea for this to be possible but it seems anyone 
wanting to do that is pretty deeply into the detail of the implementation.

In that case either "id" of "js_id" would seem appropriate.

>
>> I don't see right away where you could have multiple plots without an
>> HTML wrapper, in which case it is the title of the wrapper that will get
>> displayed. Maybe I'm missing some case you are aware of.
>
> Christoph points out that the current scheme doesn't deal well with
> multiplot mode.  All the plots in a multiplot get the same name.

See my reply to Christoph, they don't get the same value, one is wrong. 
I found what looks like a simple slip up in the source.


>
> 	Ethan
>

regards.

Re: svg : gnuplot_plot_1

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 20 October 2011, pl...@pi... wrote:
> On 10/20/11 02:17, Ethan A Merritt wrote:
> How about:
> 
> svg name is a javascript variable and has restrictions (eg no spaces or 
> dots '.' ).

If you want to hide the technical details from the user, wouldn't it
be better to avoid mention of javascript and simply say:

   "name" must not contain spaces or punctuation

> Of course , parsing the name as I suggested would probably prevent the 
> user needing to know what a valid js variable name is. He probably 
> should not need this level of knowledge to plot a graph. 
> >>> Would it be
> >>> better to substitute spaces with underscores internally when composing
> >>> the id and allow spaces in name, and hence the visible title?

It depends on who you expect to be the typical user.
I have used svg mostly in the context of  making web pages, and most
of my experience came from adapting the automated script for 
generating gnuplot's collection of on-line demos.  Because it's an
automated script, it depends on the "name" being used exactly as
specified.  If the program were to do any character substitution
then the corresponding javascript generated by the script would
not find a plot element with the appropriate name.

> ... the title which is visible in the viewer. In the case of firefox 
> it appears in the tab title and the currently displayed tab's title is 
> also shown in FF window title bar.

Aha.  But this only seems to be relevant if you point the browser 
directly at the svg file itself, rather than at an html/xml document that
contains the svg file.  I hadn't noticed, because I don't
normally use the browser that way.

I have no objection to adding a "title" keyword, that defaults to the
bare plot name if not provided.  For that matter, perhaps the keyword
"name" should be "jsname"?  Anyhow, at some point it would be nice to
add a new section to the documentation dealing with generation of web
pages. The concerns with javascript namespace, etc, are also relevant
to the HTML5 canvas terminal.

> I don't see right away where you could have multiple plots without an 
> HTML wrapper, in which case it is the title of the wrapper that will get 
> displayed. Maybe I'm missing some case you are aware of.

Christoph points out that the current scheme doesn't deal well with
multiplot mode.  All the plots in a multiplot get the same name.

	Ethan

Re: svg : gnuplot_plot_1

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

On 10/20/11 13:40, Christoph Bersch wrote:
> On 20.10.2011 09:26, pl...@pi... wrote:
>> On 10/20/11 02:17, Ethan A Merritt wrote:
>>>
>>> It is absolutely necessary.  That is how the document distinguishes which
>>> elements belong to plot 1, which to plot 2, and so on.  That way it is
>>> possible to globally toggle properties of one plot without affecting the
>>> others.  These, by the way, are multiple plots within the same graph.
>>> If there are multiple graphs in the document, then we have globally
>>> accessible handles for
>>>       name1_plot_1 ... name1_plot_N
>>>       name2_plot_1 ... name2_plot_M
>>> and so on.
>>
>> Yes, I appreciate why you need different and unique ID's , this is a
>> well thought out feature .
>
> Besides the id vs. title issue, there is a bug related to theses plot
> numbers in multiplot graphs:
>
> set terminal svg mouse
> set output 'multiplot.svg'
> set multiplot layout 1, 2
> plot sin(x), cos(x)
> plot x**2
> unset multiplot
> set output
>
> Now, clicking on the key of the x**2 plot hides/shows the sin(x) plot.
>
> I just mention it here, because it is related to the naming of the
> unique ids.
>
> Christoph
>
> -------------------------------

<g id="gnuplot_canvas" onclick="gnuplot_svg.toggleCoordBox(evt)" 
onmousemove="gnuplot_svg.moveCoordBox(evt)">

seems to be a slip up between canvas and svg output in multiplot. Second 
one gets "gnuplot_plot_1"

regards.

Re: svg : gnuplot_plot_1

[Christoph B. <us...@be...>]

On 20.10.2011 09:26, pl...@pi... wrote:
> On 10/20/11 02:17, Ethan A Merritt wrote:
>>
>> It is absolutely necessary.  That is how the document distinguishes which
>> elements belong to plot 1, which to plot 2, and so on.  That way it is
>> possible to globally toggle properties of one plot without affecting the
>> others.  These, by the way, are multiple plots within the same graph.
>> If there are multiple graphs in the document, then we have globally
>> accessible handles for
>>      name1_plot_1 ... name1_plot_N
>>      name2_plot_1 ... name2_plot_M
>> and so on.
>
> Yes, I appreciate why you need different and unique ID's , this is a
> well thought out feature .

Besides the id vs. title issue, there is a bug related to theses plot 
numbers in multiplot graphs:

set terminal svg mouse
set output 'multiplot.svg'
set multiplot layout 1, 2
plot sin(x), cos(x)
plot x**2
unset multiplot
set output

Now, clicking on the key of the x**2 plot hides/shows the sin(x) plot.

I just mention it here, because it is related to the naming of the 
unique ids.

Christoph

Re: svg : gnuplot_plot_1

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

On 10/20/11 02:17, Ethan A Merritt wrote:
> On Wednesday, October 19, 2011 03:57:09 pm pl...@pi... wrote:
>>> Since I raised the topic , there are two things there the id and the
>>> title, name gets used for both.
>>>
>>> Clearly id cannot have spaces so attempting a name with a space throws
>>> an error, though
>>> " line 133: illegal javascript variable name" is a bit cryptic unless
>>> one is familiar with the mechanics of svg.
>
> Well, it really is the javascript that cares, not the svg.
> But feel free to suggest a more helpful error message.

I fully agree it is accurate and it is js syntax that requires it but to 
a user trying to make a graph they're just going to say "WTF!?"  .  The 
message makes sense to the programmer but is totally out of context for 
the user.

How about:

svg name is a javascript variable and has restrictions (eg no spaces or 
dots '.' ).

Of course , parsing the name as I suggested would probably prevent the 
user needing to know what a valid js variable name is. He probably 
should not need this level of knowledge to plot a graph.

>
>>> A title with underscores, though legible, is not too pretty. Would it be
>>> better to substitute spaces with underscores internally when composing
>>> the id and allow spaces in name, and hence the visible title?
>
> Sorry, I don't understand what you are suggesting there.  What do you mean
> by the "visible" title?  Visible to whom?  Using what tool?
>

You seem to have missed my point earlier that name is used twice. Once 
as svg id , once as svg title.

It is the title which is visible in the viewer. In the case of firefox 
it appears in the tab title and the currently displayed tab's title is 
also shown in FF window title bar.

Showing the filename or  title in the application title bar is fairly 
common and I would expect this on other viewers as well.

So TITLE is visible and has no js restrictions, ID has the restrictions 
you pointed out.



>> PS I've just noticed that even when I do specify a name , the svg title
>> still gets "plot_1" appended to the name I specified.
>>
>> Is this necessary in some way , or is it an oversight?
>
> It is absolutely necessary.  That is how the document distinguishes which
> elements belong to plot 1, which to plot 2, and so on.  That way it is
> possible to globally toggle properties of one plot without affecting the
> others.  These, by the way, are multiple plots within the same graph.
> If there are multiple graphs in the document, then we have globally
> accessible handles for
>     name1_plot_1 ... name1_plot_N
>     name2_plot_1 ... name2_plot_M
> and so on.
>

Yes, I appreciate why you need different and unique ID's , this is a 
well thought out feature .
Again , I think this is simply that you missed my distinction about id 
vs. title.

I see no reason why the svg title has to be affected plot_N . I don't 
see right away where you could have multiple plots without an HTML 
wrapper, in which case it is the title of the wrapper that will get 
displayed. Maybe I'm missing some case you are aware of.

> Note that someone requested a more complex namespace
>   https://sourceforge.net/tracker/?func=detail&aid=3205221&group_id=2055&atid=352055
> and Christoph Bersch put together a patch that may or may not satisfy
> the request.  Neither Christoph nor I am sufficiently knowledgeable about
> svg to judge whether the request is reasonable and whether the patch
> implements it correctly.   Please help us by adding your thoughts, if you can.
>
> 	Ethan
>

svg title element is a text element that is intended to be human 
readable, it is not part of the namespace.

I'll look at the patch , but I'm not sure that I'm a qualified svg 
standards inspector ;)

Thanks again.

Re: svg : gnuplot_plot_1

[Ethan A M. <sf...@us...>]

On Wednesday, October 19, 2011 03:57:09 pm pl...@pi... wrote:
> > Since I raised the topic , there are two things there the id and the
> > title, name gets used for both.
> >
> > Clearly id cannot have spaces so attempting a name with a space throws
> > an error, though
> > " line 133: illegal javascript variable name" is a bit cryptic unless
> > one is familiar with the mechanics of svg.

Well, it really is the javascript that cares, not the svg.
But feel free to suggest a more helpful error message.

> > A title with underscores, though legible, is not too pretty. Would it be
> > better to substitute spaces with underscores internally when composing
> > the id and allow spaces in name, and hence the visible title?

Sorry, I don't understand what you are suggesting there.  What do you mean
by the "visible" title?  Visible to whom?  Using what tool?

> PS I've just noticed that even when I do specify a name , the svg title 
> still gets "plot_1" appended to the name I specified.
> 
> Is this necessary in some way , or is it an oversight?

It is absolutely necessary.  That is how the document distinguishes which
elements belong to plot 1, which to plot 2, and so on.  That way it is
possible to globally toggle properties of one plot without affecting the
others.  These, by the way, are multiple plots within the same graph.
If there are multiple graphs in the document, then we have globally
accessible handles for
   name1_plot_1 ... name1_plot_N
   name2_plot_1 ... name2_plot_M
and so on.

Note that someone requested a more complex namespace
 https://sourceforge.net/tracker/?func=detail&aid=3205221&group_id=2055&atid=352055
and Christoph Bersch put together a patch that may or may not satisfy 
the request.  Neither Christoph nor I am sufficiently knowledgeable about
svg to judge whether the request is reasonable and whether the patch
implements it correctly.   Please help us by adding your thoughts, if you can.

	Ethan

Re: svg : gnuplot_plot_1

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

On 10/20/11 00:41, pl...@pi... wrote:
> On 10/19/11 23:53, Ethan Merritt wrote:
>> On Wednesday, October 19, 2011 02:03:54 pm pl...@pi... wrote:
>>> Hi,
>>>
>>> unless I've missed something in help there does not seem any way to set
>>> the svg<title>   when using that terminal.
>>>
>>> All plots get :
>>>
>>> <g id="gnuplot_plot_1"><title>gnuplot_plot_1</title>
>>>
>>>
>>> When I open several plots in a viewer (eg firefox) seeing them all named
>>> gnuplot_plot_1 is not too helpful.
>>>
>>> I thought of using the gnuplot title here but since plot titles tend to
>>> be rather verbose , this may not be the best idea.
>>>
>>> Since this is fairly specific to svg , maybe a better idea is to add it
>>> to the terminal setting syntax:
>>>
>>>
>>>     Syntax:
>>>           set terminal svg {size<x>,<y>   {|fixed|dynamic}}
>>>                            {{no}enhanced}
>>>                            {fname "<font>"} {fsize<fontsize>}
>>>                            {mouse} {jsdir<dirname>} {name<plotname>}
>>                                                        ^^^^^^^^^^^^^^^^^
>>>                            {font "<fontname>{,<fontsize>}"}
>>>                            {fontfile<filename>}
>>>                            {rounded|butt} {solid|dashed} {linewidth<lw>}
>>>                            {background<rgb_color>}
>>
>> It's in there already:
>> 	set term svg name "myplot"
>>
>> This is exactly the mechanism used to generate the demo pages
>> so that you can toggle the curves in one plot on/off without
>> affecting curves in other plots on the same page.
>> E.g.
>>       http://gnuplot.sourceforge.net/demo_svg_4.5/simple.html
>>
>>
>> 	Ethan
>>
> Apologies Ethan,
> maybe I could only see what is was expecting to see and didn't realise
> name was what I wanted.
>
> Since I raised the topic , there are two things there the id and the
> title, name gets used for both.
>
> Clearly id cannot have spaces so attempting a name with a space throws
> an error, though
> " line 133: illegal javascript variable name" is a bit cryptic unless
> one is familiar with the mechanics of svg.
>
> A title with underscores, though legible, is not too pretty. Would it be
> better to substitute spaces with underscores internally when composing
> the id and allow spaces in name, and hence the visible title?
>
> Thanks.
>
PS I've just noticed that even when I do specify a name , the svg title 
still gets "plot_1" appended to the name I specified.

Is this necessary in some way , or is it an oversight?

regards, Peter.

Re: svg : gnuplot_plot_1

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

On 10/19/11 23:53, Ethan Merritt wrote:
> On Wednesday, October 19, 2011 02:03:54 pm pl...@pi... wrote:
>> Hi,
>>
>> unless I've missed something in help there does not seem any way to set
>> the svg<title>  when using that terminal.
>>
>> All plots get :
>>
>> <g id="gnuplot_plot_1"><title>gnuplot_plot_1</title>
>>
>>
>> When I open several plots in a viewer (eg firefox) seeing them all named
>> gnuplot_plot_1 is not too helpful.
>>
>> I thought of using the gnuplot title here but since plot titles tend to
>> be rather verbose , this may not be the best idea.
>>
>> Since this is fairly specific to svg , maybe a better idea is to add it
>> to the terminal setting syntax:
>>
>>
>>    Syntax:
>>          set terminal svg {size<x>,<y>  {|fixed|dynamic}}
>>                           {{no}enhanced}
>>                           {fname "<font>"} {fsize<fontsize>}
>>                           {mouse} {jsdir<dirname>} {name<plotname>}
>                                                       ^^^^^^^^^^^^^^^^^
>>                           {font "<fontname>{,<fontsize>}"}
>>                           {fontfile<filename>}
>>                           {rounded|butt} {solid|dashed} {linewidth<lw>}
>>                           {background<rgb_color>}
>
> It's in there already:
> 	set term svg name "myplot"
>
> This is exactly the mechanism used to generate the demo pages
> so that you can toggle the curves in one plot on/off without
> affecting curves in other plots on the same page.
> E.g.
>      http://gnuplot.sourceforge.net/demo_svg_4.5/simple.html
>
>
> 	Ethan
>
Apologies Ethan,
maybe I could only see what is was expecting to see and didn't realise 
name was what I wanted.

Since I raised the topic , there are two things there the id and the 
title, name gets used for both.

Clearly id cannot have spaces so attempting a name with a space throws 
an error, though
" line 133: illegal javascript variable name" is a bit cryptic unless 
one is familiar with the mechanics of svg.

A title with underscores, though legible, is not too pretty. Would it be 
better to substitute spaces with underscores internally when composing 
the id and allow spaces in name, and hence the visible title?

Thanks.

Re: svg : gnuplot_plot_1

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

On Wednesday, October 19, 2011 02:03:54 pm pl...@pi... wrote:
> Hi,
> 
> unless I've missed something in help there does not seem any way to set 
> the svg <title> when using that terminal.
> 
> All plots get :
> 
> <g id="gnuplot_plot_1" ><title>gnuplot_plot_1</title>
> 
> 
> When I open several plots in a viewer (eg firefox) seeing them all named 
> gnuplot_plot_1 is not too helpful.
> 
> I thought of using the gnuplot title here but since plot titles tend to 
> be rather verbose , this may not be the best idea.
> 
> Since this is fairly specific to svg , maybe a better idea is to add it 
> to the terminal setting syntax:
> 
> 
>   Syntax:
>         set terminal svg {size <x>,<y> {|fixed|dynamic}}
>                          {{no}enhanced}
>                          {fname "<font>"} {fsize <fontsize>}
>                          {mouse} {jsdir <dirname>} {name <plotname>}
                                                     ^^^^^^^^^^^^^^^^^
>                          {font "<fontname>{,<fontsize>}"}
>                          {fontfile <filename>}
>                          {rounded|butt} {solid|dashed} {linewidth <lw>}
>                          {background <rgb_color>}

It's in there already:
	set term svg name "myplot"

This is exactly the mechanism used to generate the demo pages 
so that you can toggle the curves in one plot on/off without
affecting curves in other plots on the same page.
E.g.
    http://gnuplot.sourceforge.net/demo_svg_4.5/simple.html


	Ethan




> -->                        {title <svg title>}
> 
> best regards, Peter.
> 
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

svg : gnuplot_plot_1

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

Hi,

unless I've missed something in help there does not seem any way to set 
the svg <title> when using that terminal.

All plots get :

<g id="gnuplot_plot_1" ><title>gnuplot_plot_1</title>


When I open several plots in a viewer (eg firefox) seeing them all named 
gnuplot_plot_1 is not too helpful.

I thought of using the gnuplot title here but since plot titles tend to 
be rather verbose , this may not be the best idea.

Since this is fairly specific to svg , maybe a better idea is to add it 
to the terminal setting syntax:


  Syntax:
        set terminal svg {size <x>,<y> {|fixed|dynamic}}
                         {{no}enhanced}
                         {fname "<font>"} {fsize <fontsize>}
                         {mouse} {jsdir <dirname>} {name <plotname>}
                         {font "<fontname>{,<fontsize>}"}
                         {fontfile <filename>}
                         {rounded|butt} {solid|dashed} {linewidth <lw>}
                         {background <rgb_color>}
-->                        {title <svg title>}

best regards, Peter.

Dead link in gnuplot faq

[Andreas S. <a_s...@un...>]

Hello,

i tried downloading the fileftp.dartmouth.edu in pub/gnuplot/latex.shar 
<ftp://ftp.dartmouth.edupub/gnuplot/latex.shar> which is in your 
gnuplot-faq unter Section 6.3 
(http://www.gnuplot.info/faq/faq.html#SECTION00083000000000000000), but 
the link seems to be dead. Do you know the correct link?

Thanks
Andreas Sprenger

Re: adding svg click on legend to other interactives

[Bastian M. <bma...@we...>]

Am 17.10.2011 10:04, schrieb pl...@pi...:
> Hi,
>
> I have been working with the click on legend feature using svg and it is
> incredibly useful.
>

Btw. for the canvas terminal this feature is implemented via additional
controls.

> I am quickly starting to miss this when working in wxt and find myself
> adding svg creation just so I can flip to svg in firefox instead of wxt.
>
> Wouldn't this be a nice feature to add other interactive terminals like
> wxt? Presumably that would be fairly simple to do.
>

Recently, a similar feature was added for the windows terminal. It was 
straight forward to implement, since drawing commands are already cached 
in a list for screen updates.

Bastian


> best regards, Peter.

Re: adding svg click on legend to other interactives

[sfeam (E. Merritt) <eam...@gm...>]

On Monday, 17 October 2011, pl...@pi... wrote:
> Hi,
> 
> I have been working with the click on legend feature using svg and it is 
> incredibly useful.
> 
> I am quickly starting to miss this when working in wxt and find myself 
> adding svg creation just so I can flip to svg in firefox instead of wxt.
> 
> Wouldn't this be a nice feature to add other interactive terminals like 
> wxt? Presumably that would be fairly simple to do.

You are welcome to try :-)

The thing is, languages like svg nest the drawing commands into groups.  
You can then do something that operates on the whole group as a unit,
in this case turn it on or off.  Very few of the other graphics output
modes work that way.  I don't say it would be impossible, but you'd have
to take a very different approach to implement this behaviour.

	Ethan

adding svg click on legend to other interactives

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

Hi,

I have been working with the click on legend feature using svg and it is 
incredibly useful.

I am quickly starting to miss this when working in wxt and find myself 
adding svg creation just so I can flip to svg in firefox instead of wxt.

Wouldn't this be a nice feature to add other interactive terminals like 
wxt? Presumably that would be fairly simple to do.

best regards, Peter.

Re: Release plans: Version 4.4.4 and beyond

[Tatsuro M. <tma...@ya...>]

Hello

--- On Fri, 2011/10/14, sfeam (Ethan Merritt)  wrote:
> > BTW, I have forgotten the way to check out branch-4-4-stable source.
> > Please inform me.
> 
>    cvs checkout -r branch-4-4-stable gnuplot

I have confirmed that the src/stdfn.c in branch-4-4-stable branch is fixed. 
Thanks.

Regards

Tatsuro

Re: spurious 'if' error after fault

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 13 October 2011, sfeam (Ethan Merritt) wrote:
> On Thursday, 13 October 2011, pl...@pi... wrote:
> > Hi,
> > 
> > I don't know exactly what the function eval error is but the break in 
> > execution seems to highlight a bug in the new if/then/else error trapping.
> > 
> > Seems the parser is set half way though an if block and then gets 
> > confused when I reload the file.

Never mind. I think I see the issue.
The "Undefined value during function evaluation" message comes from
"fit". The "fit" subsystem has its own error-handling routine error_ex()
rather than calling int_error() like the rest of the program.
But error_ex() does not do all the cleanup that int_error() does.
We need to either add calls to the various cleanup routines in error_ex()
or modify "fit" to call int_error() like everyone else. 

	Ethan



> > 
> > Otherwise the new syntax makes life a lot easier. Thanks.
> > 
> > Don't know if this is important .
> > 
> > regards. Peter.
> > 
> > 
> > 
> > gnuplot> load "doublet_integral.gnu
> >           Undefined value during function evaluation
> 
> disregarding this one for a moment (although of course it might be crucial)...
>  
> > gnuplot> load "doublet_integral.gnu
> > 
> > gnuplot> if (use_SD) outfilebase=outfilebase."SD_fit."
> >                       ^
> >           "doublet_integral.gnu", line 65: Old-style if/else statement 
> > encountered inside brackets
> > gnuplot> load "doublet_integral.gnu
> >           Undefined value during function evaluation
> 
> I don't know how to make that first error message any clearer, but I'm
> open to suggestions.   An old-style "if" with no { ... } clause
> causes the entire rest of the current bracketed clause to be skipped.
> Given that an unknown number of input commands were skipped, 
> it's hardly surprising that error messages about things like
> undefined values might occur later.
> 
> There is currently a bug (at least I consider it a bug) in the
> "load" command that might also be relevant.  If you nest several
> load commands, and the deepest one says "exit", it is supposed to 
> back out of this level and resume execution at the previous level.
> Instead the current cvs version falls back all the way to the top
> level of execution.  I don't know exactly when this bug crept in,
> but it's been there for a while now.
> 
> If you think your scripts demonstrate a failure not explained by
> either of these factors, please attach them to a bug report on
> SourceForge so that we can have a look at it.
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: spurious 'if' error after fault

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 13 October 2011, pl...@pi... wrote:
> Hi,
> 
> I don't know exactly what the function eval error is but the break in 
> execution seems to highlight a bug in the new if/then/else error trapping.
> 
> Seems the parser is set half way though an if block and then gets 
> confused when I reload the file.
> 
> Otherwise the new syntax makes life a lot easier. Thanks.
> 
> Don't know if this is important .
> 
> regards. Peter.
> 
> 
> 
> gnuplot> load "doublet_integral.gnu
>           Undefined value during function evaluation

disregarding this one for a moment (although of course it might be crucial)...
 
> gnuplot> load "doublet_integral.gnu
> 
> gnuplot> if (use_SD) outfilebase=outfilebase."SD_fit."
>                       ^
>           "doublet_integral.gnu", line 65: Old-style if/else statement 
> encountered inside brackets
> gnuplot> load "doublet_integral.gnu
>           Undefined value during function evaluation

I don't know how to make that first error message any clearer, but I'm
open to suggestions.   An old-style "if" with no { ... } clause
causes the entire rest of the current bracketed clause to be skipped.
Given that an unknown number of input commands were skipped, 
it's hardly surprising that error messages about things like
undefined values might occur later.

There is currently a bug (at least I consider it a bug) in the
"load" command that might also be relevant.  If you nest several
load commands, and the deepest one says "exit", it is supposed to 
back out of this level and resume execution at the previous level.
Instead the current cvs version falls back all the way to the top
level of execution.  I don't know exactly when this bug crept in,
but it's been there for a while now.

If you think your scripts demonstrate a failure not explained by
either of these factors, please attach them to a bug report on
SourceForge so that we can have a look at it.

Re: Release plans: Version 4.4.4 and beyond

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 12 October 2011, Tatsuro MATSUOKA wrote:
> Hello
> 
> --- On Thu, 2011/10/13, Ethan A Merritt  wrote:
> 
> > Could it be because the test in stdfn.c is different?
> > Version 4.4        #if defined(__MINGW__)
> > Version 4.5        #if defined(__MINGW32__)
> 
> You are right.
> Using #if defined(__MINGW32__) for gnuplot 4.4.3 source,
> give the correct results.
> 
> gnuplot> print NaN
> NaN
> 
> Please modify the branch-4-4-stable source.
> BTW, I have forgotten the way to check out branch-4-4-stable source.
> Please inform me.

   cvs checkout -r branch-4-4-stable gnuplot

	Ethan

spurious 'if' error after fault

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

Hi,

I don't know exactly what the function eval error is but the break in 
execution seems to highlight a bug in the new if/then/else error trapping.

Seems the parser is set half way though an if block and then gets 
confused when I reload the file.

Otherwise the new syntax makes life a lot easier. Thanks.

Don't know if this is important .

regards. Peter.



gnuplot> load "doublet_integral.gnu
          Undefined value during function evaluation

gnuplot> load "doublet_integral.gnu

gnuplot> if (use_SD) outfilebase=outfilebase."SD_fit."
                      ^
          "doublet_integral.gnu", line 65: Old-style if/else statement 
encountered inside brackets

gnuplot> load "doublet_integral.gnu
          Undefined value during function evaluation

Re: Release plans: Version 4.4.4 and beyond

[Tatsuro M. <tma...@ya...>]

Hello

--- On Thu, 2011/10/13, Ethan A Merritt  wrote:

> Could it be because the test in stdfn.c is different?
> Version 4.4        #if defined(__MINGW__)
> Version 4.5        #if defined(__MINGW32__)

You are right.
Using #if defined(__MINGW32__) for gnuplot 4.4.3 source,
give the correct results.

gnuplot> print NaN
NaN

Please modify the branch-4-4-stable source.
BTW, I have forgotten the way to check out branch-4-4-stable source.
Please inform me.

Regards

Tatsuro