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.