Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2011-10-19 21:43:27
|
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.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2011-10-19 21:56:17
|
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
|
|
From: <pl...@pi...> - 2011-10-19 22:41:50
|
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.
|
|
From: <pl...@pi...> - 2011-10-19 22:57:17
|
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.
|
|
From: Ethan A M. <sf...@us...> - 2011-10-20 00:35:56
|
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 |
|
From: <pl...@pi...> - 2011-10-20 11:03:26
|
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. |
|
From: Christoph B. <us...@be...> - 2011-10-20 11:53:02
|
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 |
|
From: <pl...@pi...> - 2011-10-20 15:33:25
|
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. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-20 15:47:22
|
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 |
|
From: <pl...@pi...> - 2011-10-20 23:53:28
|
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. |
|
From: Ethan A M. <sf...@us...> - 2011-10-21 01:00:08
|
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 |
|
From: <pl...@pi...> - 2011-10-21 05:15:00
|
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.
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-21 05:32:50
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2011-10-21 05:44:08
|
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 |
|
From: Christoph B. <us...@be...> - 2011-10-21 08:15:01
|
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 |
|
From: Ethan A M. <sf...@us...> - 2011-10-21 19:00:11
|
On Friday, October 21, 2011 01:14:52 am Christoph Bersch wrote: > 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 Thanks. Sounds good. Do people agree that the logical thing to put here would be the title of the overall graph - the one controlled by "set title ..."? The text of "set title" is not currently visible to the drivers, though. One possibility is to add a new terminal entry point term->title(const char *text) I do not know off the top of my head how many terminal types would benefit, but it seems likely we could use it at least for svg, canvas, PostScript, and pdf. Ethan |
|
From: <pl...@pi...> - 2011-10-21 08:47:00
|
On 10/21/11 07:43, Ethan Merritt wrote: > 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 > > OK, I just thought you may ask for a suggestion for the help. You can obviously do better. For the latter problem add a title tag after <desc> , see my other reply. Peter. |
|
From: <pl...@pi...> - 2011-10-21 08:27:33
Attachments:
firefox-svg.png
|
On 10/21/11 07:32, sfeam (Ethan Merritt) wrote: > 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). > OK, I have attached a screenshot that probably won't get through the ML but you are on CC so at least you should get it. I see FF using svg title in two places. The browser window title bar as you describe above. With an html document this shows the html title so this seems consistent and correct. Also I see it in the browser tab. I suspect this is configurable in FF options so you may or may not see that. ( this is firefox 3.6.20 ) I have given up using opera for svg since it opens local svg files as text. A bug I reported over a year ago and remains AFAIK unaddressed. I have to upload somewhere and access via http so I no long bother. I manually edited the svg as follows and FF tab and title bar now show the modified title with spaces. <g id="25u50u_25cZZ_plot_1" ><title>25u50u 25cZZ plot 1</title> It seems FF is just grabbing the first occurrence of ANY title element, this may not be that logical. If the intent is to have an svg title for the file maybe that can best be addressed by adding a new svg element near the head of the file. I just tried this between <desc> and <script> tags and it works. I believe that is correct usage but you may like to check. I suspect FF picking up the plot element's title may be a bug , but explicitly adding a title to the file would seem to be the correct approach for situations where a viewer displays it. This also works with Opera , it is only displaying the file name as you noted because there is no title tag in the document. This is probably what FF should be doing as well. So adding a new title tag for the document as a whole seems the right thing to do. A trivial mod. Using any specified "title" option also as the base text for the plot titles would allow control of the text shown in the hint box you describe too. (I don't think there are any distro/desktop issues complicating this.) Regards, Peter. > 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 > > |
|
From: Tait <gnu...@t4...> - 2011-10-24 09:19:26
|
pl...@pi... said (on 2011/10/21): > I have given up using opera for svg since it opens local svg files > as text. A bug I reported over a year ago and remains AFAIK > unaddressed. I have to upload somewhere and access via http so I no > long bother. Odd... I don't have that problem. Local SVGs open fine for me. I'm currently using 11.52 on Windows, but I've been using Opera to view SVGs since at least 9.something. |
|
From: <pl...@pi...> - 2011-10-22 07:08:48
|
On 10/21/11 20:55, Ethan A Merritt wrote: > On Friday, October 21, 2011 01:14:52 am Christoph Bersch wrote: >> 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 > > Thanks. Sounds good. Yes, that seems clearly the correct location for the document title tag. > Do people agree that the logical thing to put here would be the > title of the overall graph - the one controlled by "set title ..."? Not really. The gnuplot title would typically be too verbose. eg "correlation of spectral FWHM to instrument slit width." , or some such. Graph titles are generally quite descriptive. Graph titles have to say quite a lot. This may be far too long to be useful in a tab title (often cropped off at a dozen or so characters,or the window title bar text which is usually length limited as well. Using the current name option would be preferable to make these two the same. What I find useful as a distinct label in the browser is often some snippet of the full title that allows me to differentiate between several plot versions displayed concurrently. eg. gnuplot title for graph: "As_193.7nm_HIB1365_50u50u_DC2.SD_fit" svg name "50u50u_DC2.SD_fit" It is the 50u50u_DC2 that I need to see to differentiate concurrently displayed plots. They all start with "As_193.7nm" as dictated by the title required on the report's SVG output. I think confounding the two would be a retrograde step/ > > The text of "set title" is not currently visible to the drivers, though. > One possibility is to add a new terminal entry point > term->title(const char *text) > I do not know off the top of my head how many terminal types would > benefit, but it seems likely we could use it at least for svg, canvas, > PostScript, and pdf. > > Ethan > Your earlier suggestion of having this as a separate option in 'set terminal svg ..." seemed good. If this can really be useful to several terminals a global approach may have some merit and making it visible to the driver would make sense. What is passed, however, would be subject to comments above. Are the uses made of title by the other terminals functionally similar (eg space limitations and cropping ) such that forcing identical formatting makes sense? In my context, the true graph title has very different criteria to what is useful in the browser tab and title bar to identify what I'm looking at , which does not need to be verbose but needs to be short and unique. Similarity of name ; svg "title" and gnuplot "title" , should not be assumed to be a similarity of function. I think the two have very different requirements. My bottom line suggestion: gnuplot title is part of the final , terminal agnostic (possibly printable) output. This is truly part of the graph and can not be compromised by the user to fit in with something else. It is not necessarily a good choice for other uses. In fact, probably isn't. set terminal svg name <svg title> changes to : ... svg title <svg title> to avoid potentially confusing alternative names for same thing. This will generally be much shorter than gnuplot's: set title <visible plot title> . Help should explain that this is the document title and that it does no appear in the graph. If specified, that svg title would also be the base text for <g> titles on the plot lines as well. (though not the id's) new "id" or "js_id" option for svg and canvas that, when given, is the base for variable names with all that implies. If not given revert to current "gnuplot_1_x " syndrome with any needed bug fixes. None of that should affect the namespace changes suggested elsewhere if that done later. best regards, Peter. |
|
From: <pl...@pi...> - 2011-10-22 08:25:51
|
On 10/22/11 08:32, pl...@pi... wrote: > Using > the current name option would be preferable to make these two the same. > Sorry that should have read: Using the current name option would be preferable to _making_ these two the same. Please note the tab title is not a FF foible, opera does it too. (Opera was the first to present tabbed browsing and FF copied. Kudos to Opera for this innovation.) Peter. |
|
From: <pl...@pi...> - 2011-10-24 06:42:46
|
On 10/22/11 17:45, Ethan Merritt wrote:
> set term foo
>
> set output 'plot1.foo'
> set title "Graphs AB"
> plot "A.dat" title "A", "B.dat" title "B"
>
> set output 'plot2.foo'
> set title "Graphs CDE"
> plot "C.dat", "D.dat", "E.dat"
>
> ... and so on for many plots
>
> I
There seem to be two ways to satisfy this sort of case:
1. a new global variable like set title , let's call it set doctitle.
This could be reset without reopening the terminal.
2. use existing gnuplot and reopen the terminal with a new "name". This
is somewhat of a work around but seems a reasonable one.
When I suggested a new option to set output I was referring to
something like 1 , since output is a variable , not an object it can't
itself have options.
In the case of 1. help would explain that variable only affects some
terminals (canvas,svg,pdf , etc) and is ignored where it is irrelevant.
2. Presents a compat issue for canvas since this is already out in the
field. The terminal could default to existing behaviour if both are
present,
Option 1 would seem to be the most structured solution since, as you
have pointed out, this is not actually a property of the terminal.
Your code example (with more realistic plot titles) becomes :
set term foo
set output 'plot1.foo'
set doctitle "Corell A vs B"
set title "Correlation ceofficient of quantity A against quantity B"
plot "A.dat" title "A", "B.dat" title "B"
set output 'plot2.foo'
set doctitle "Corell C vs DE"
set title "Correlation ceofficient of quantity C against quantity
D and E"
plot "C.dat", "D.dat", "E.dat"
This also addresses the corollary issue that I brought up: the need for
a visible name to conform to js syntax rules and the resulting untidy
need for underscores.
terminal "name" would become in effect "js_id" . Its use would not
compromise visible elements and errors would make more sense. Nothing
would prevent automated scripts from using the same (js valid) string
for both if that was desired.
Does the above scheme fit in with your requirements?
It's probably worth making the right choice at this stage since further
compatibility issues will arise for changes made later, as features get
into stable releases.
best regards, Peter.
|
|
From: Tait <gnu...@t4...> - 2011-10-24 12:30:24
|
I dislike option 2, for the reasons already stated. (It's not a terminal property, and I don't want to re-"set term" for every plot.) I'm okay with "set doctitle" as long as it defaults, if unspecified, to whatever "set title" is. > There seem to be two ways to satisfy this sort of case: > > 1. a new global variable like set title , let's call it set doctitle. > This could be reset without reopening the terminal. > > 2. use existing gnuplot and reopen the terminal with a new "name". This > is somewhat of a work around but seems a reasonable one. > > ... > Your code example (with more realistic plot titles) becomes : > > set term foo > > set output 'plot1.foo' > set doctitle "Corell A vs B" > set title "Correlation ceofficient of quantity A against quantity B" > plot "A.dat" title "A", "B.dat" title "B" > > set output 'plot2.foo' > set doctitle "Corell C vs DE" > set title "Correlation ceofficient of quantity C against quantity > D and E" > plot "C.dat", "D.dat", "E.dat" |
|
From: Christoph B. <us...@be...> - 2011-10-22 11:24:49
|
On 22.10.2011 08:32 pl...@pi... wrote: > > My bottom line suggestion: > > gnuplot title is part of the final , terminal agnostic (possibly > printable) output. This is truly part of the graph and can not be > compromised by the user to fit in with something else. It is not > necessarily a good choice for other uses. In fact, probably isn't. > > set terminal svg name <svg title> changes to : ... svg title <svg > title> to avoid potentially confusing alternative names for same thing. > This will generally be much shorter than gnuplot's: set title <visible > plot title> . Help should explain that this is the document title and > that it does no appear in the graph. I agree with you, this looks like a good approach. This must be done separately for each terminal driver for which it makes sense (canvas, svg, postscript, pdfcairo etc). Christoph |
|
From: Ethan M. <merritt@u.washington.edu> - 2011-10-22 15:46:21
|
On Saturday, 22 October 2011, Christoph Bersch wrote:
> On 22.10.2011 08:32 pl...@pi... wrote:
> >
> > My bottom line suggestion:
> >
> > gnuplot title is part of the final , terminal agnostic (possibly
> > printable) output. This is truly part of the graph and can not be
> > compromised by the user to fit in with something else. It is not
> > necessarily a good choice for other uses. In fact, probably isn't.
> >
> > set terminal svg name <svg title> changes to : ... svg title <svg
> > title> to avoid potentially confusing alternative names for same thing.
> > This will generally be much shorter than gnuplot's: set title <visible
> > plot title> . Help should explain that this is the document title and
> > that it does no appear in the graph.
>
> I agree with you, this looks like a good approach.
But this assumes that you re-open the terminal driver before
every plot. That hasn't been my practice in the past, and I
suspect I'm not the only one with gnuplot scripts in daily
use that don't do this. The generic usage up until now has
been as below, and again I point to the demo scripts, not
because they are important per se but just because they
illustrate the scripting style.
set term foo
set output 'plot1.foo'
set title "Graphs AB"
plot "A.dat" title "A", "B.dat" title "B"
set output 'plot2.foo'
set title "Graphs CDE"
plot "C.dat", "D.dat", "E.dat"
... and so on for many plots
I don't see the advantage in requiring that the terminal be
re-opened between plots just so that the title is updated.
If such scripts are not re-written, then under your suggestion
the page displaying graphs CDE will be labelled "Graphs AB".
Ethan
|
