Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2011-10-21 08:36:41
|
On 10/21/11 10:14, Christoph Bersch wrote: > 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 > Thanks for the link. <http://www.w3.org/TR/2000/CR-SVG-20001102/struct.html#DescriptionAndTitleElements> >> Authors should always provide a 'title' child element to the outermost 'svg' element within a stand-alone SVG document. The 'title' child element to an 'svg' element serves the purposes of identifying the content of the given SVG document fragment. Since users often consult documents out of context, authors should provide context-rich titles. >> It seems gnuplot should be adding such a title at the outermost level as I suggested doing. Peter. |
|
From: <pl...@pi...> - 2011-10-22 16:53:45
|
On 10/22/11 17:45, Ethan Merritt wrote: > 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 > There is a logical inconsistency it would seem. The svg title is more a property of the plot than of the terminal. Correct me if I am wrong but I suppose all the features we are discussing here are established in stable releases and hence pose a problem of backwards compatibility if they are changed. Specifically , does that apply to the 'name' option? I see on your demo titles of the following form: <g id="simple_3_plot_1" ><title>simple_3_plot_1</title> could you explain how that is created or post a link to the scripts that make it? Peter. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-22 18:38:30
|
On Saturday, 22 October 2011, pl...@pi... wrote: > I see on your demo titles of the following form: > > <g id="simple_3_plot_1" ><title>simple_3_plot_1</title> > > could you explain how that is created or post a link to the scripts that > make it? The demos are all in the distribution package under .../demo/ and the scripts for generating the html pages from them are under .../demo/html/ There are parallel scripts and Makefiles for png svg and canvas. Ethan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-22 18:48:11
|
On Saturday, 22 October 2011, pl...@pi... wrote: > There is a logical inconsistency it would seem. The svg title is more a > property of the plot than of the terminal. That's the way I understand it. > Correct me if I am wrong but I suppose all the features we are > discussing here are established in stable releases and hence pose a > problem of backwards compatibility if they are changed. Specifically , > does that apply to the 'name' option? The mousing version of the svg terminal is only in the CVS branch, so no, this doesn't affect svg in the released version 4.4 But the equivalent "name" option support to support mousing is in the released version of the canvas terminal. Currently the PostScript and PDF terminals write a prologue record /Title (<filename>) but there have been many complaints from people who don't like the way that some external tools handle this. They suffer from a problem equivalent to the one you originally complained about, that the title of the first [last?] plot is displayed as if it were the title of the whole document the plot is embedded in. If you look on the Feature Request and Bug trackers, you'll find requests to change this and not write a Title record at all. Ethan |
|
From: <pl...@pi...> - 2011-10-22 20:26:59
|
On 10/22/11 20:38, sfeam (Ethan Merritt) wrote: > On Saturday, 22 October 2011, pl...@pi... wrote: >> I see on your demo titles of the following form: >> >> <g id="simple_3_plot_1"><title>simple_3_plot_1</title> >> >> could you explain how that is created or post a link to the scripts that >> make it? > > The demos are all in the distribution package under .../demo/ > and the scripts for generating the html pages from them > are under .../demo/html/ > There are parallel scripts and Makefiles for png svg and canvas. > > Ethan > thanks, print GNUPLOT "set term svg enhanced font 'arial,10' mouse name \"$name"."_$plot\" jsdir '.' size 600,400 dynamic\n"; so it seems that you are using the 'name' feature in set term svg to create the names you want. That presumably requires the reopening of the terminal that you were objecting to earlier. It would also mean a rewrite if this is moved to plot. While each of your arguments has merit it seems something will break what ever is done. Name in canvas is out in stable so that's a bit inconvenient. If it was just a rename to 'title' name could be retained as pseudo for compatibility. Unless I'm misreading what is being done, your objection to closing svg terminal would not affect your scripts which seem to do this already. > 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" > So the svg title is not so much a property of the plot but the output file. Perhaps the title option should be there and rendered when it has meaning for the terminal .This relates to your earlier comment about making it visible to the terminals via a new interface. Is this also true for the other cases of title , would a new approach here address the issues with pdf etc ? Peter. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-22 20:43:12
|
On Saturday, 22 October 2011, pl...@pi... wrote: > print GNUPLOT "set term svg enhanced font 'arial,10' mouse name > \"$name"."_$plot\" jsdir '.' size 600,400 dynamic\n"; > > so it seems that you are using the 'name' feature in set term svg to > create the names you want. That presumably requires the reopening of the > terminal that you were objecting to earlier. It does not. Just look at the script. The terminal is opened only once per demo. Ethan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-22 21:01:57
|
On Saturday, 22 October 2011, pl...@pi... wrote: > So the svg title is not so much a property of the plot but the output > file. Part of the problem here is that the SVG spec doesn't say what <title> is supposed to do. It is left up to the implementation of the viewer. Furthermore, the <title> element is valid at multiple levels, and the viewer is apparently free to different things with the titles at different levels. Let me recap. Up until our current discussion, the <title> element was being used inside the group bounding each indivual plot within the graph. The behavior I observe for firefox/chrome/konqueror/opera is that when the title is encountered at this level it is used to provide a pop-up information box on mouse-over. Firefox, but not the other browsers, _also_ uses the title of the first group to label the window. I actually think that's a bug, but the spec does allow it. The current discussion is about adding a <title> element at the top level, which is a different thing. Firefox/opera/chrome, but not konqueror, use a title at the top level to label the window if it is present. I've added that to the svg terminal driver in CVS. There's a wrinkle, however. It actually makes more sense to have the window label match the file name, which is what all the browsers except firefox were doing before. The reason I think this is that every file is guaranteed to get a new name, whereas unless you keep closing and re-opening the terminal the "name" attribute will remain the same across files. This means that for all files except the first one, the name shown in the browser window bar will probably be wrong. The code I added to CVS loads the top level title with "name". But for the reasons stated above I'm not entirely happy with that. Either the file name or the plot title (from "set title") makes more sense to me. Ethan |
|
From: <pl...@pi...> - 2011-10-23 05:59:43
|
On 10/22/11 23:01, sfeam (Ethan Merritt) wrote: > On Saturday, 22 October 2011, pl...@pi... wrote: >> So the svg title is not so much a property of the plot but the output >> file. > > Part of the problem here is that the SVG spec doesn't say what<title> > is supposed to do. It is left up to the implementation of the viewer. > Furthermore, the<title> element is valid at multiple levels, and the > viewer is apparently free to different things with the titles at different > levels. > > Let me recap. > > Up until our current discussion, the<title> element was being used > inside the group bounding each indivual plot within the graph. > The behavior I observe for firefox/chrome/konqueror/opera is that > when the title is encountered at this level it is used to provide > a pop-up information box on mouse-over. Firefox, but not the other > browsers, _also_ uses the title of the first group to label the > window. I actually think that's a bug, but the spec does allow it. > Agreed , this seems more accidental than intentional. I Opera's use of the file name in absence of a top level title is more appropriate. It does not mean no title is the best content to generate. If file name is determined to be the best text to display , title should be set to that. > The current discussion is about adding a<title> element at the top level, > which is a different thing. Firefox/opera/chrome, but not konqueror, > use a title at the top level to label the window if it is present. > I've added that to the svg terminal driver in CVS. > > There's a wrinkle, however. It actually makes more sense to have the > window label match the file name, which is what all the browsers except > firefox were doing before. The reason I think this is that every file > is guaranteed to get a new name, A unique title for each file would be useful. That is what I would like to see in short tab titles in FF and Opera. To be clear about the tabs I'm referring to that can only display a short text here's a screen-shot. This is the immediate point of reference when viewing several files at a time and is where the need for a shorter text is than the filename or the graph title is seen. http://piments.com/tmp/opera-tabs.png The three files here are: 1. A web based URL with an svg from gnuplot before recent changes. 2. An html wrapper on a local server that opera decides to display the whole URL not the fn. 3. File with "name" based top level svg title. > whereas unless you keep closing and > re-opening the terminal the "name" attribute will remain the same across > files. Which suggests, as I said in my last post, that this is a property, not of the terminal nor of the plot but of the file. It should probably be an option to set output. Many of the problems an inconsistencies seem to derive from the fact that this option is tied to the terminal , which is sufficient for trivial cases like one plot at each invocation of the terminal but falls apart with more complex stuff like the demos. > This means that for all files except the first one, the name > shown in the browser window bar will probably be wrong. > > The code I added to CVS loads the top level title with "name". > But for the reasons stated above I'm not entirely happy with that. > Either the file name or the plot title (from "set title") makes > more sense to me. > > Ethan > That solution seems an improvement but has the short-comings you pointed out for complex plots. I don't use the other terminals enough to comment on how this affects the other issue that have causes complaints. Neither to I do complex multiplots. You clearly have a much more thorough understanding having worked closely on all this. Your complaints seem to indicate that , whatever the text finally is, it cannot be derived from a one off option in set terminal. Since this svg title is an attribute of an svg file (that can then have derivative names for graphs and plot lines in that file ) and you see a need for that name to be unique to each file the obvious and correct place to set this would seem to be when the file is opened, ie as an option to set output. Could you comment on whether that would fit the logic of more complex plots? Peter. |
|
From: Christoph B. <us...@be...> - 2011-10-23 10:57:58
|
On 22.10.2011 20:47 sfeam (Ethan Merritt) wrote: > > Currently the PostScript and PDF terminals write a prologue record > /Title (<filename>) > but there have been many complaints from people who don't like the > way that some external tools handle this. They suffer from a problem > equivalent to the one you originally complained about, that the > title of the first [last?] plot is displayed as if it were the title > of the whole document the plot is embedded in. If you look on the > Feature Request and Bug trackers, you'll find requests to change > this and not write a Title record at all. I think, there had also been people complaining about the automatic insertion of the author's login name in postscript files. So this <title> we are talking about, has a different purpose than the one of "set title", the filename is not appropriate, and any terminal option does not fit the usual scripting workflow. A possiblity would then be, like Peter suggested, to add an option 'title' (and maybe also other file properties like 'author' and 'desc') to "set output", or even a single 'set ...' option which handles different file meta data and to have the current behavior as fallback if the new options are not used. Christoph |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-23 17:41:44
|
On Saturday, 22 October 2011, pl...@pi... wrote: > http://piments.com/tmp/opera-tabs.png > > The three files here are: > 1. A web based URL with an svg from gnuplot before recent changes. > 2. An html wrapper on a local server that opera decides to display the > whole URL not the fn. > 3. File with "name" based top level svg title. So Firefox chooses to display different things, depending on exactly how you point it at the file. And other browsers make other choices. I think you are presenting a good case that we should not spend too much effort worrying about the <title> attribute. > [the] correct place to set this would seem to be when the file is opened, > ie as an option to set output. > Could you comment on whether that would fit the logic of more complex > plots? "set output" deals only with controlling the output stream. It knows nothing about the current terminal type or plot attributes. The one thing the program remembers after a "set output" command is the filename, which indeed is what the PostScript terminal currently uses as a title. But for other terminals it may make no sense at all. Consider: set output '|display png:-' Not very useful as a plot or window title :-) Is your objection to using the current command "set title" only that the title might not fit in a browser index tab? Ethan |
|
From: <pl...@pi...> - 2011-10-23 19:17:19
|
On 10/23/11 19:41, sfeam (Ethan Merritt) wrote: > On Saturday, 22 October 2011, pl...@pi... wrote: >> http://piments.com/tmp/opera-tabs.png >> >> The three files here are: >> 1. A web based URL with an svg from gnuplot before recent changes. >> 2. An html wrapper on a local server that opera decides to display the >> whole URL not the fn. >> 3. File with "name" based top level svg title. > > So Firefox chooses to display different things, depending on exactly how > you point it at the file. Errm, you will notice I was refering to Opera there not FF. Also point of 2 above was that it was NOT an svg but HTML and shows that display of filenames is not consistent. 1 and 3 differ because 3 is using "name". This was to show how it offered more control. So ,no, this was nothing to do with FF and did not show different behaviour wrt svg depending on how the file was opened. The whole point is that browsers seem to take different choices of what to do if there is no title defined. Getting more consistency would be one reason to define what we want in a coherent way that browsers can display consistently . > And other browsers make other choices. > I think you are presenting a good case that we should not spend too much > effort worrying about the<title> attribute. I think I am presenting a good case why this needs to be dealt with correctly, not ignored. You are free to see things differently , of course. > >> [the] correct place to set this would seem to be when the file is opened, >> ie as an option to set output. >> Could you comment on whether that would fit the logic of more complex >> plots? > > "set output" deals only with controlling the output stream. > It knows nothing about the current terminal type or plot attributes. > The one thing the program remembers after a "set output" command > is the filename, which indeed is what the PostScript terminal > currently uses as a title. But for other terminals it may make no > sense at all. Consider: > set output '|display png:-' > Not very useful as a plot or window title :-) Please read what I wrote. I in nowhere suggested that the current argument for "output" should be used as the svg title. My point was that if you consider this to be a function of the file rather than the terminal (a possition that I have agreed makes sense) it should be dealt with at the time the output file is determined. This means it has to be in set output. It was you who said you thought using terminal "name" was not good and objected to reopening the terminal to reset it. That makes some sense but the overhead of reopening does not seem prohibitive. Going with you idea that this is out of place in set terminal would mean a new option in set output , not using the value of output itself. > > Is your objection to using the current command "set title" > only that the title might not fit in a browser index tab? > My objection is that it _almost certainly_ will not fit in the tab. Opera seems to give it 12 characters. There is little chance that a the plot -title will be that short , thus the text in tab , which is the primary focal point when switching between tabs is rendered of little use for gnuplot svg output. The mod you just committed fixes this from my point of view (thanks) but you seem unhappy with it. I was trying to find a more rigorous solution that would satisfy your more complicated usage. If you are not interested in taking it any further I'll drop it. Current cvs fits my needs fine. regards, Peter. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-23 17:47:07
|
On Sunday, 23 October 2011, Christoph Bersch wrote: > On 22.10.2011 20:47 sfeam (Ethan Merritt) wrote: > > > > Currently the PostScript and PDF terminals write a prologue record > > /Title (<filename>) > > but there have been many complaints from people who don't like the > > way that some external tools handle this. > > I think, there had also been people complaining about the automatic > insertion of the author's login name in postscript files. Yes. So we removed it: ChangeLog (both 4.4 and 4.5) 2010-03-06 Ethan A Merritt <merritt@u.washington.edu> * src/util.c configure.in config/config.cyg config/config.dj2 config/config.mgw config/config.ntconfig/config.os2 config/config.oww: Remove the test for pwd.h, the configuration flag HAVE_PWD_H, and the conditional code that copies GECOS information from the password file into the header of PostScript and PDF output files. This addresses reported issues of privacy and reported problems with building a static executable. I considered removing the /Title at the same time, but settled for documenting a way to disable generation of the corresponding PDFMark by editing the locally installed PostScript prolog template. Ethan |
|
From: Christoph B. <us...@be...> - 2011-10-24 07:16:28
|
On 23.10.2011 19:46, sfeam (Ethan Merritt) wrote: > On Sunday, 23 October 2011, Christoph Bersch wrote: >> On 22.10.2011 20:47 sfeam (Ethan Merritt) wrote: >>> >>> Currently the PostScript and PDF terminals write a prologue record >>> /Title (<filename>) >>> but there have been many complaints from people who don't like the >>> way that some external tools handle this. >> >> I think, there had also been people complaining about the automatic >> insertion of the author's login name in postscript files. > > Yes. So we removed it: > > ChangeLog (both 4.4 and 4.5) > 2010-03-06 Ethan A Merritt<merritt@u.washington.edu> > * src/util.c configure.in config/config.cyg config/config.dj2 > config/config.mgw config/config.ntconfig/config.os2 config/config.oww: > Remove the test for pwd.h, the configuration flag HAVE_PWD_H, and the > conditional code that copies GECOS information from the password file > into the header of PostScript and PDF output files. This addresses > reported issues of privacy and reported problems with building a static > executable. I only saw, that in the CVS version (14. Oct) with the postscript terminal the login name still is written to the output file. Only after your mail I found in the sources, that this information is taken from the 'USER' or 'USERNAME' environment variable. Still I think that some kind of settings for the title, author name, description and maybe other meta data makes sense, and then one has a defined interface on how to set these properties. Christoph |
