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

Re: key text placement in SVG

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

On Friday, 12 October 2012, Daniel J Sebald wrote:
> > Counting capitals would be a good first step. Since this is a once per
> > plot overhead, some detailed accounting would not have any noticeable
> > performance hit.
> 
> Counting capitals goes along the lines one doesn't want to go.  The 
> proper way of doing this is either to have scalable fonts, or for the 
> library to have a convenient function by which the programmer can 
> provide the font type/size and an ASCII string of the text to be placed 
> and the routine returns the size when rendered.  Font substitution is a 
> get-what-you-get sort of thing.

The fonts are scalable. That's not the problem.
There are routines that return font metrics, but in order for it to 
make any sense they must be called by (or at least in the same context as)
the program that is displaying the result.  Calling such a library from
inside gnuplot would at best only an approximation based on rendering some
other font in some other environment.

pl...@pi... wrote>
> The nice thing about SVG is the ability to zoom in to get more detail. 
> Doing this on Allin's example , comparing Firefox to Opera on linux, 
> the U of UNEMP is basically outside the plot with the second upright on 
> the y-axis.
> 
> With Opera is it perfectly coincident this the y axis, on FF it is just 
> inside the graph with a very fine amount of white separating it from the 
> axis.
> 
> A more exacting test case could provide some useful metrics on the problem.

But how would that help?  Aren't you illustrating that the _same file_
produces different results when displayed by different viewing programs?

I have found one ray of hope, however.  There is a project called
@font-face  <http://www.font-face.com/>  that attempts to define a
mechanism for achieving cross-browser consistency in font display.
I haven't had time to look into it seriously, but at first glance it
seems like it might be a way to upgrade gnuplot's text handling for
web display via the canvas terminal.  I don't know whether it is
relevant to SVG, however.  If someone wants to look into it more
deeply, that would be great.

	Ethan

[PATCH] Another pm3d corners2color function

[Clement L. <the...@gm...>]

Hello,

I've written up another pm3d corners2color function. It works just as
the others, i.e.,

set pm3d corners2color rms

rms4 takes the root mean square[1] of the four corners

The RMS has many physical interpretations [2]. Later on, I may write a
similar function for standard deviation...

My field of research is computational (statistical) physics. I make
heavy use of pm3d to represent three variable systems. As such, more
corners2color functions will come in useful.

The patch I've attached here was generated as advised using diff -ur
/orig/source/tree/ /my/source/tree/

Clement Law

[1] http://en.wikipedia.org/wiki/Root_mean_square
[2] http://en.wikipedia.org/wiki/Root_mean_square#Uses

Re: key text placement in SVG

[Daniel J S. <dan...@ie...>]

On 10/12/2012 01:08 AM, pl...@pi... wrote:
> On 10/12/12 01:43, Allin Cottrell wrote:
>> On Thu, 11 Oct 2012, Ethan A Merritt wrote:
>>
>>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>>>> I'm comparing the output of gnuplot's svg and pngcairo
>>>>> drivers, with a thought of making greater use of SVG. But
>>>>> there seems to be a slight problem with the placement of key
>>>>> text in the SVG output. Here's a little test script
>>>>>
>>>>> set term svg font "Sans,8" size 680,400
>>>>> set output 'test.svg'
>>>>> set key left top
>>>>> plot sin(x) title "PRIME" w l, \
>>>>>     cos(x) title "UNEMP" w l
>>>>> set term pngcairo font "Sans,8" size 680,400
>>>>> set output 'test.png'
>>>>> replot
>>>>>
>>>>> In the PNG version the key is just fine, but in SVG the "U" of
>>>>> "UNEMP" gets tangled up with the y-axis (more or less,
>>>>> depending on the magnification).
>>>>
>>>> The underlying issue is that for SVG, like PostScript, gnuplot has
>>>> to guess at the font properties for a font that will not actually
>>>> be selected until the file is later viewed in another program.
>>>
>>> By the way, if you turn on the "box" attribute of the key you can
>>> see that the key box itself is properly placed.  The problem is that in
>>> your case the width of the box is too small because the size of the text
>>> was underestimated.
>>>
>>> As a work-around, you could use "set key left Left".
>>> That anchors the left end of the text rather than the right end,
>>> so it is not at risk of overwriting the left plot border.
>>> Instead the right end of the text might run into the line sample ;-)
>>
>> Ah, that's a nice suggestion. I can manipulate the key placement so
>> as to try to avoid colliding with the plot lines, just so long as
>> I'm reasonably confident it won't collide with the axes.
>>
>> But on the more general point, does this mean I might have better
>> luck if a specified the font more precisely than just "Sans"?
>>
>> Allin Cottrell
>>
>
> Yes, I have taken to specifying the font size and name explicitly and
> using spaces to avoid this kind of over-run as Daniel suggested.
>
> It really would be good if some improvement could be made in this area.
> With longer key titles, the errors can be substantial.
>
> It is a bit of a guessing game but it seems that the guesses are
> always(?) rather poor.

It's awful.  Working with fonts has historically been a headache.  Save 
tweaking font position for the last touch up on graphs.


> Counting capitals would be a good first step. Since this is a once per
> plot overhead, some detailed accounting would not have any noticeable
> performance hit.

Counting capitals goes along the lines one doesn't want to go.  The 
proper way of doing this is either to have scalable fonts, or for the 
library to have a convenient function by which the programmer can 
provide the font type/size and an ASCII string of the text to be placed 
and the routine returns the size when rendered.  Font substitution is a 
get-what-you-get sort of thing.


> Clearly text content can not be counted on to average out on such short
> samples, 'emmission spectrum" with not have the same average letter
> width as " illiterate infallibility"
>
> Perhaps some quantitative study of real examples of which fonts render
> poorly on which renderers would permit better guesses to be build into
> gnuplot.
>
> Clearly there are thousands of fonts but maybe certain families are
> consistently wider / narrower so more knowledge would help improve
> built-in guesses and also help users avoid fonts that can't be estimated
> reliably.
>
> There may well be some platform dependency in all this as well. That
> would be harder to fix but probably needs assessing.  Are fonts
> consistently rendering different widths on linux / Mac / Win. ?

That should be factored into the routine that indicates rendered widths, 
if one existed.

Dan

Re: key text placement in SVG

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

On 10/12/12 01:43, Allin Cottrell wrote:
> On Thu, 11 Oct 2012, Ethan A Merritt wrote:
>
>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>>> I'm comparing the output of gnuplot's svg and pngcairo
>>>> drivers, with a thought of making greater use of SVG. But
>>>> there seems to be a slight problem with the placement of key
>>>> text in the SVG output. Here's a little test script
>>>>
>>>> set term svg font "Sans,8" size 680,400
>>>> set output 'test.svg'
>>>> set key left top
>>>> plot sin(x) title "PRIME" w l, \
>>>>    cos(x) title "UNEMP" w l
>>>> set term pngcairo font "Sans,8" size 680,400
>>>> set output 'test.png'
>>>> replot
>>>>
>>>> In the PNG version the key is just fine, but in SVG the "U" of
>>>> "UNEMP" gets tangled up with the y-axis (more or less,
>>>> depending on the magnification).
>>>
>>> The underlying issue is that for SVG, like PostScript, gnuplot has
>>> to guess at the font properties for a font that will not actually
>>> be selected until the file is later viewed in another program.
>>
>> By the way, if you turn on the "box" attribute of the key you can
>> see that the key box itself is properly placed.  The problem is that in
>> your case the width of the box is too small because the size of the text
>> was underestimated.
>>
>> As a work-around, you could use "set key left Left".
>> That anchors the left end of the text rather than the right end,
>> so it is not at risk of overwriting the left plot border.
>> Instead the right end of the text might run into the line sample ;-)
>
> Ah, that's a nice suggestion. I can manipulate the key placement so
> as to try to avoid colliding with the plot lines, just so long as
> I'm reasonably confident it won't collide with the axes.
>
> But on the more general point, does this mean I might have better
> luck if a specified the font more precisely than just "Sans"?
>
> Allin Cottrell
>

Yes, I have taken to specifying the font size and name explicitly and 
using spaces to avoid this kind of over-run as Daniel suggested.

It really would be good if some improvement could be made in this area. 
With longer key titles, the errors can be substantial.

It is a bit of a guessing game but it seems that the guesses are 
always(?) rather poor.

Counting capitals would be a good first step. Since this is a once per 
plot overhead, some detailed accounting would not have any noticeable 
performance hit.

Clearly text content can not be counted on to average out on such short 
samples, 'emmission spectrum" with not have the same average letter 
width as " illiterate infallibility"

Perhaps some quantitative study of real examples of which fonts render 
poorly on which renderers would permit better guesses to be build into 
gnuplot.

Clearly there are thousands of fonts but maybe certain families are 
consistently wider / narrower so more knowledge would help improve 
built-in guesses and also help users avoid fonts that can't be estimated 
reliably.

There may well be some platform dependency in all this as well. That 
would be harder to fix but probably needs assessing.  Are fonts 
consistently rendering different widths on linux / Mac / Win. ?

Perhaps Ethan (who probably knows better than most how to manifest the 
differences) could produce a test script an we could return screenshots 
of various renderings on different  platforms and software.

regards, Peter.

Re: key text placement in SVG

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

On 10/12/12 01:43, Allin Cottrell wrote:
> On Thu, 11 Oct 2012, Ethan A Merritt wrote:
>
>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>>> I'm comparing the output of gnuplot's svg and pngcairo
>>>> drivers, with a thought of making greater use of SVG. But
>>>> there seems to be a slight problem with the placement of key
>>>> text in the SVG output. Here's a little test script
>>>>
>>>> set term svg font "Sans,8" size 680,400
>>>> set output 'test.svg'
>>>> set key left top
>>>> plot sin(x) title "PRIME" w l, \
>>>>    cos(x) title "UNEMP" w l
>>>> set term pngcairo font "Sans,8" size 680,400
>>>> set output 'test.png'
>>>> replot
>>>>

The nice thing about SVG is the ability to zoom in to get more detail. 
Doing this on Allin's example , comparing Firefox to Opera on linux, 
the U of UNEMP is basically outside the plot with the second upright on 
the y-axis.

With Opera is it perfectly coincident this the y axis, on FF it is just 
inside the graph with a very fine amount of white separating it from the 
axis.

A more exacting test case could provide some useful metrics on the problem.

Peter.

Re: key text placement in SVG

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

On Thu, 11 Oct 2012, Ethan A Merritt wrote:

> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>> I'm comparing the output of gnuplot's svg and pngcairo
>>> drivers, with a thought of making greater use of SVG. But
>>> there seems to be a slight problem with the placement of key
>>> text in the SVG output. Here's a little test script
>>>
>>> set term svg font "Sans,8" size 680,400
>>> set output 'test.svg'
>>> set key left top
>>> plot sin(x) title "PRIME" w l, \
>>>   cos(x) title "UNEMP" w l
>>> set term pngcairo font "Sans,8" size 680,400
>>> set output 'test.png'
>>> replot
>>>
>>> In the PNG version the key is just fine, but in SVG the "U" of
>>> "UNEMP" gets tangled up with the y-axis (more or less,
>>> depending on the magnification).
>>
>> The underlying issue is that for SVG, like PostScript, gnuplot has
>> to guess at the font properties for a font that will not actually
>> be selected until the file is later viewed in another program.
>
> By the way, if you turn on the "box" attribute of the key you can
> see that the key box itself is properly placed.  The problem is that in
> your case the width of the box is too small because the size of the text
> was underestimated.
>
> As a work-around, you could use "set key left Left".
> That anchors the left end of the text rather than the right end,
> so it is not at risk of overwriting the left plot border.
> Instead the right end of the text might run into the line sample ;-)

Ah, that's a nice suggestion. I can manipulate the key placement so 
as to try to avoid colliding with the plot lines, just so long as 
I'm reasonably confident it won't collide with the axes.

But on the more general point, does this mean I might have better 
luck if a specified the font more precisely than just "Sans"?

Allin Cottrell

Re: key text placement in SVG

[Daniel J S. <dan...@ie...>]

On 10/11/2012 06:31 PM, Ethan A Merritt wrote:
> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>> I'm comparing the output of gnuplot's svg and pngcairo
>>> drivers, with a thought of making greater use of SVG. But
>>> there seems to be a slight problem with the placement of key
>>> text in the SVG output. Here's a little test script
>>>
>>> set term svg font "Sans,8" size 680,400
>>> set output 'test.svg'
>>> set key left top
>>> plot sin(x) title "PRIME" w l, \
>>>    cos(x) title "UNEMP" w l
>>> set term pngcairo font "Sans,8" size 680,400
>>> set output 'test.png'
>>> replot
>>>
>>> In the PNG version the key is just fine, but in SVG the "U" of
>>> "UNEMP" gets tangled up with the y-axis (more or less,
>>> depending on the magnification).
>>
>> The underlying issue is that for SVG, like PostScript, gnuplot has
>> to guess at the font properties for a font that will not actually
>> be selected until the file is later viewed in another program.
>
> By the way, if you turn on the "box" attribute of the key you can
> see that the key box itself is properly placed.  The problem is that in
> your case the width of the box is too small because the size of the text
> was underestimated.
>
> As a work-around, you could use "set key left Left".
> That anchors the left end of the text rather than the right end,
> so it is not at risk of overwriting the left plot border.
> Instead the right end of the text might run into the line sample ;-)

One might be able to put a space at the front or end of the text to 
compensate for that as well. (And there might even be some parameters 
associated with key text that can be adjusted.)  The easiest alternative 
is probably to look for a font that both gnuplot can use for width 
information and that the SVG driver can use for display.

Dan


>
> 	Ethan
>
>
>
>
>> Here is the relevant code snippet from svg.trm:
>>
>> /* since we cannot interrogate SVG about text properties and according
>>   * to SVG 1.0 W3C Candidate Recommendation 2 August 2000 the
>>   * "line-height" of the 'text' element is defined to be equal to the
>>   * 'font-size' (!), we have to to define font properties in a less
>>   * than optimal way */
>>      SVG_fontAscent = (int) (SVG_fontSizeCur * 1.00 * SVG_SCALE);
>>      SVG_fontDescent = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
>>      SVG_fontLeading = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
>>      SVG_fontAvWidth = (int) (SVG_fontSizeCur * 0.70 * SVG_SCALE);
>>
>> Apparently for the font your viewer is choosing in response to a
>> request for "Sans", the average character width is greater than
>> 70% of the nominal font size.  It would be easy enough to bump
>> SVG_fontAvWidth up to 0.8 or something, but I imagine that in
>> turn might be too wide for other viewer+font+text combinations.
>>
>> Contributing to the problem in your particular example is that fact that
>> the title is in all caps, and capital letters are wider than the "average"
>> letter in most proportionally-spaced fonts.  We might be able to address
>> this part of the problem by modifying gnuplot's string width estimator
>> to bump up the estimate if there are many capital letters in the string.
>>
>> 	Ethan
>>
>>
>>
>>
>>
>>> I'm looking at the SVG using
>>> librsvg, and also via the Adobe NPSVG3 library. To show what
>>> I'm talking about, I'm attaching the SVG output as converted
>>> to PNG by rsvg-convert (at 96dpi).
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: key text placement in SVG

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

On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
> > I'm comparing the output of gnuplot's svg and pngcairo 
> > drivers, with a thought of making greater use of SVG. But 
> > there seems to be a slight problem with the placement of key 
> > text in the SVG output. Here's a little test script
> > 
> > set term svg font "Sans,8" size 680,400
> > set output 'test.svg'
> > set key left top
> > plot sin(x) title "PRIME" w l, \
> >   cos(x) title "UNEMP" w l
> > set term pngcairo font "Sans,8" size 680,400
> > set output 'test.png'
> > replot
> > 
> > In the PNG version the key is just fine, but in SVG the "U" of 
> > "UNEMP" gets tangled up with the y-axis (more or less, 
> > depending on the magnification).
> 
> The underlying issue is that for SVG, like PostScript, gnuplot has
> to guess at the font properties for a font that will not actually
> be selected until the file is later viewed in another program.

By the way, if you turn on the "box" attribute of the key you can
see that the key box itself is properly placed.  The problem is that in
your case the width of the box is too small because the size of the text
was underestimated.

As a work-around, you could use "set key left Left".
That anchors the left end of the text rather than the right end,
so it is not at risk of overwriting the left plot border.
Instead the right end of the text might run into the line sample ;-)

	Ethan




> Here is the relevant code snippet from svg.trm:
> 
> /* since we cannot interrogate SVG about text properties and according
>  * to SVG 1.0 W3C Candidate Recommendation 2 August 2000 the
>  * "line-height" of the 'text' element is defined to be equal to the
>  * 'font-size' (!), we have to to define font properties in a less
>  * than optimal way */
>     SVG_fontAscent = (int) (SVG_fontSizeCur * 1.00 * SVG_SCALE);
>     SVG_fontDescent = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
>     SVG_fontLeading = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
>     SVG_fontAvWidth = (int) (SVG_fontSizeCur * 0.70 * SVG_SCALE);
> 
> Apparently for the font your viewer is choosing in response to a
> request for "Sans", the average character width is greater than
> 70% of the nominal font size.  It would be easy enough to bump
> SVG_fontAvWidth up to 0.8 or something, but I imagine that in
> turn might be too wide for other viewer+font+text combinations.
> 
> Contributing to the problem in your particular example is that fact that 
> the title is in all caps, and capital letters are wider than the "average"
> letter in most proportionally-spaced fonts.  We might be able to address
> this part of the problem by modifying gnuplot's string width estimator
> to bump up the estimate if there are many capital letters in the string.
> 
> 	Ethan
> 
> 
> 
> 
> 
> > I'm looking at the SVG using 
> > librsvg, and also via the Adobe NPSVG3 library. To show what 
> > I'm talking about, I'm attaching the SVG output as converted 
> > to PNG by rsvg-convert (at 96dpi).
> > 
> > 
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: key text placement in SVG

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

On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
> I'm comparing the output of gnuplot's svg and pngcairo 
> drivers, with a thought of making greater use of SVG. But 
> there seems to be a slight problem with the placement of key 
> text in the SVG output. Here's a little test script
> 
> set term svg font "Sans,8" size 680,400
> set output 'test.svg'
> set key left top
> plot sin(x) title "PRIME" w l, \
>   cos(x) title "UNEMP" w l
> set term pngcairo font "Sans,8" size 680,400
> set output 'test.png'
> replot
> 
> In the PNG version the key is just fine, but in SVG the "U" of 
> "UNEMP" gets tangled up with the y-axis (more or less, 
> depending on the magnification).

The underlying issue is that for SVG, like PostScript, gnuplot has
to guess at the font properties for a font that will not actually
be selected until the file is later viewed in another program.
Here is the relevant code snippet from svg.trm:

/* since we cannot interrogate SVG about text properties and according
 * to SVG 1.0 W3C Candidate Recommendation 2 August 2000 the
 * "line-height" of the 'text' element is defined to be equal to the
 * 'font-size' (!), we have to to define font properties in a less
 * than optimal way */
    SVG_fontAscent = (int) (SVG_fontSizeCur * 1.00 * SVG_SCALE);
    SVG_fontDescent = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
    SVG_fontLeading = (int) (SVG_fontSizeCur * 0.25 * SVG_SCALE);
    SVG_fontAvWidth = (int) (SVG_fontSizeCur * 0.70 * SVG_SCALE);

Apparently for the font your viewer is choosing in response to a
request for "Sans", the average character width is greater than
70% of the nominal font size.  It would be easy enough to bump
SVG_fontAvWidth up to 0.8 or something, but I imagine that in
turn might be too wide for other viewer+font+text combinations.

Contributing to the problem in your particular example is that fact that 
the title is in all caps, and capital letters are wider than the "average"
letter in most proportionally-spaced fonts.  We might be able to address
this part of the problem by modifying gnuplot's string width estimator
to bump up the estimate if there are many capital letters in the string.

	Ethan





> I'm looking at the SVG using 
> librsvg, and also via the Adobe NPSVG3 library. To show what 
> I'm talking about, I'm attaching the SVG output as converted 
> to PNG by rsvg-convert (at 96dpi).
> 
> 

key text placement in SVG

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

I'm comparing the output of gnuplot's svg and pngcairo 
drivers, with a thought of making greater use of SVG. But 
there seems to be a slight problem with the placement of key 
text in the SVG output. Here's a little test script

set term svg font "Sans,8" size 680,400
set output 'test.svg'
set key left top
plot sin(x) title "PRIME" w l, \
  cos(x) title "UNEMP" w l
set term pngcairo font "Sans,8" size 680,400
set output 'test.png'
replot

In the PNG version the key is just fine, but in SVG the "U" of 
"UNEMP" gets tangled up with the y-axis (more or less, 
depending on the magnification). I'm looking at the SVG using 
librsvg, and also via the Adobe NPSVG3 library. To show what 
I'm talking about, I'm attaching the SVG output as converted 
to PNG by rsvg-convert (at 96dpi).

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: [PATCH] better citizen gnuplot emacs mode

[Jon O. <jon...@gm...>]

Sorry all -- my earlier message to this thread was rejected for not being from my old address.

Bruce offered to set up the github repository for gnuplot-mode last year after I submitted a couple of patches. Since then I have hacked on it a bit, but haven't had time to put together anything that could be called a release. AFAIK the versions in gnuplot CVS and on Bruce's home page are the most recent official versions.

The code in the github devel branch (https://github.com/bruceravel/gnuplot-mode/tree/devel) should be stable enough to go in a new release. Apart from bugfixes, I've tried to make my additions not get in the way, so that people who don't want them can ignore them. There are some backward incompatibilities which I will fix. It would be good to be able to maintain backwards support at least for GNU Emacs 22 (from 2007; the current version is 24). I guess it should try to support XEmacs too, though that seems likely to become increasingly difficult as XEmacs development seems to have stalled.

I'm not sure of the best way to get testers for a new beta version of gnuplot-mode, since people get Emacs packages from lots of different places. How active is the gnuplot-info list?

The alternative would be to release a semi-untested version on the Emacs package sites and wait for bug reports, which seems a little shoddy. Perhaps it would be OK to upload it as "gnuplot-mode-beta", though I have never seen anyone do that.

I agree that it would be best to include any new gnuplot-mode releases back into the core gnuplot repository.

I'll also try to have a look at the code in the Debian package and see if there are any patches from there that should be merged into the main repository.

Jon


> I was unaware of any recent development being done on gnuplot-mode.  
> Bruce Ravel's old site here at UW no longer exists.  I am not an emacs 
> user and know essentially nothing about how well or poorly the old 
> gnuplot-mode code has kept up with emacs development.  I'm just the guy
> trying to keep gnuplot distribution itself up to date.  
> 
> So yeah, if the gnuplot-mode stuff is being maintained and distributed 
> elsewhere then I'm fine with removing it from the gnuplot distribution per se.  
> On the other hand, gnuplot distribution from the project repository has
> been consistent going back at least 12 years, whereas separate distribution
> of the gnuplot-mode scripts outside of gnuplot has been mostly stagnent over 
> that period.  
> 
> I'll CC Bruce to see if he has any opinion or any interest in getting back 
> in the loop.
> 
> 	Ethan    

Re: [PATCH] better citizen gnuplot emacs mode

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

On Sunday, October 07, 2012 06:09:49 pm gn...@di... wrote:
> > > The gnuplot emacs mode was creating bindings in the global comint mode,
> > > overwriting those that were already there. This resulted in breakage when those
> > > keys were used in other non-gnuplot comint buffers. Attached patch applies the
> > > bindings ONLY to the gnuplot comint instance.
> > > 
> > > dima
> >
> > On Mon, 8 Oct 2012 01:23:04 +0100
> > Jon Oddie <jon...@gm...> wrote:
> >
> > Hi,
> > 
> > You might want to check out the more recent version of gnuplot-mode at https://github.com/bruceravel/gnuplot-mode . I have done a bit of work on it in the past year, including creating a separate `gnuplot-comint-mode' for the comint buffer, which I think may solve the same problem as your patch. Let me know if I'm wrong.
> > 
> > I think it's also on the MELPA repo, tho not in Marmalade yet.
> > 
> > There are some other features on the way, including better tab completion and documentation lookup, and displaying images inline in Emacs. Take a look at the devel branch on github if you're interested. I think they are reasonably stable, but have not tested on many different Emacs setups.
> > 
> > Once it has had more testing, it would eventually be good to get a newer version of gnuplot-mode incorporated into a gnuplot release.
> 
> Oh, I see. That's great; I'd much rather use the actively-developed tree instead
> of my patches to an old tree. This thing seems to be in a bit of disarray right
> now. The latest release on Bruce's site (not the github) dates back to 2002. The
> copies in the gnuplot tree and in debian
> (http://packages.debian.org/sid/gnuplot-mode) are all patched versions of that
> old release.
> 
> Ethan, can we remove gnuplot-mode from the gnuplot CVS entirely? Currently it's
> out of date, and active development is happening entirely elsewhere. To make
> matters even worse, the copy in CVS doesn't even have a link to the latest
> development tree. At the same time, I'd like to get the Debian package up to
> date too. Jon, is the code currently in that git repo ready for release, or does
> it still need work?
> 
> dima

I was unaware of any recent development being done on gnuplot-mode.  
Bruce Ravel's old site here at UW no longer exists.  I am not an emacs 
user and know essentially nothing about how well or poorly the old 
gnuplot-mode code has kept up with emacs development.  I'm just the guy
trying to keep gnuplot distribution itself up to date.  

So yeah, if the gnuplot-mode stuff is being maintained and distributed 
elsewhere then I'm fine with removing it from the gnuplot distribution per se.  
On the other hand, gnuplot distribution from the project repository has
been consistent going back at least 12 years, whereas separate distribution
of the gnuplot-mode scripts outside of gnuplot has been mostly stagnent over 
that period.  So just from the point of view of having a long-term 
distribution mode it might be better to merge the more recent development 
back into the gnuplot repository.  

I'll CC Bruce to see if he has any opinion or any interest in getting back 
in the loop.

	Ethan    

Re: [PATCH] better citizen gnuplot emacs mode

[Mojca M. <moj...@gm...>]

On Mon, Oct 8, 2012 at 3:09 AM,  <gn...@di...> wrote:
>
> Ethan, can we remove gnuplot-mode from the gnuplot CVS entirely? Currently it's
> out of date, and active development is happening entirely elsewhere.

Gnuplot project could be updated from another repository every now and
then. (There is no need to entirely remove the code. Those who don't
want to have it installed can always use --without-lisp-files and
fetch the files from other source.)

Mojca

Re: Variable color demo page (website)

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

On Sunday, 07 October 2012, sfeam (Ethan Merritt) wrote:
> On Sunday, 07 October 2012, Tait wrote:
> > > ...
> > > Or are you asking how to get an existing demo like varcolor.dem
> > > included in the on-line collection?
> > > The thing is, there's not room on one page to index
> > > every demo in the collection...
> > 
> > Why not? I doubt many people run all the demos when they need help,
> > and some distributions don't include the demos. The demos left out of
> > the demos web page effectively don't exist for user help purposes.
> > 
> > It might be worthwhile to explore a more image-centric
> > layout. (http://gallery.r-enthusiasts.com/thumbs.php)
> 
> That gallery is pretty nice.
> If anyone wants to put together an equivalent interface for
> gnuplot demos, I'm all for it.  But I think we would have to
> find a separate site to host that sort of dynamic content.
> So far as I know, SourceForge only offers to host static content.

Hmm. I take that back.  Even though their top-level description of
project services only mentions static web content, if you drill down
to 
 https://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web%20and%20developer%20web%20platform
it seems to say that PHP scripting is supported.
Not that I know anything about using PHP, but if someone wants
to tackle it, I'll help set up the necessary SourceForge access.
Any volunteers?

	Ethan

Re: Variable color demo page (website)

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

On Sunday, 07 October 2012, Tait wrote:
> > ...
> > Or are you asking how to get an existing demo like varcolor.dem
> > included in the on-line collection?
> > The thing is, there's not room on one page to index
> > every demo in the collection...
> 
> Why not? I doubt many people run all the demos when they need help,
> and some distributions don't include the demos. The demos left out of
> the demos web page effectively don't exist for user help purposes.
> 
> It might be worthwhile to explore a more image-centric
> layout. (http://gallery.r-enthusiasts.com/thumbs.php)

That gallery is pretty nice.
If anyone wants to put together an equivalent interface for
gnuplot demos, I'm all for it.  But I think we would have to
find a separate site to host that sort of dynamic content.
So far as I know, SourceForge only offers to host static content.
Then again, it is possible to do some pretty amazing stuff via
CSS, so maybe...

	Ethan

Re: Variable color demo page (website)

[Tait <gnu...@t4...>]

> ...
> Or are you asking how to get an existing demo like varcolor.dem
> included in the on-line collection?
> The thing is, there's not room on one page to index
> every demo in the collection...

Why not? I doubt many people run all the demos when they need help,
and some distributions don't include the demos. The demos left out of
the demos web page effectively don't exist for user help purposes.

It might be worthwhile to explore a more image-centric
layout. (http://gallery.r-enthusiasts.com/thumbs.php is disorganized,
but gives a general idea.) People often know, visually, what they want,
but not the correct names and keywords to get that result.

Re: [PATCH] better citizen gnuplot emacs mode

[<gn...@di...>]

> > The gnuplot emacs mode was creating bindings in the global comint mode,
> > overwriting those that were already there. This resulted in breakage when those
> > keys were used in other non-gnuplot comint buffers. Attached patch applies the
> > bindings ONLY to the gnuplot comint instance.
> > 
> > dima
>
> On Mon, 8 Oct 2012 01:23:04 +0100
> Jon Oddie <jon...@gm...> wrote:
>
> Hi,
> 
> You might want to check out the more recent version of gnuplot-mode at https://github.com/bruceravel/gnuplot-mode . I have done a bit of work on it in the past year, including creating a separate `gnuplot-comint-mode' for the comint buffer, which I think may solve the same problem as your patch. Let me know if I'm wrong.
> 
> I think it's also on the MELPA repo, tho not in Marmalade yet.
> 
> There are some other features on the way, including better tab completion and documentation lookup, and displaying images inline in Emacs. Take a look at the devel branch on github if you're interested. I think they are reasonably stable, but have not tested on many different Emacs setups.
> 
> Once it has had more testing, it would eventually be good to get a newer version of gnuplot-mode incorporated into a gnuplot release.

Oh, I see. That's great; I'd much rather use the actively-developed tree instead
of my patches to an old tree. This thing seems to be in a bit of disarray right
now. The latest release on Bruce's site (not the github) dates back to 2002. The
copies in the gnuplot tree and in debian
(http://packages.debian.org/sid/gnuplot-mode) are all patched versions of that
old release.

Ethan, can we remove gnuplot-mode from the gnuplot CVS entirely? Currently it's
out of date, and active development is happening entirely elsewhere. To make
matters even worse, the copy in CVS doesn't even have a link to the latest
development tree. At the same time, I'd like to get the Debian package up to
date too. Jon, is the code currently in that git repo ready for release, or does
it still need work?

dima

Re: [PATCH] New pm3d corners2color function

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

On Sunday, 07 October 2012, Petr Mikulik wrote:
> > However, the pm3d code currently treats NaN as if it were zero anyhow,
> > so as a practical matter the plot would not come out any different.
> >
> > The "with image" plot modes recognize NaN and do not draw the corresponding
> > rectangular pixel.  Should we make pm3d do the same?
> > I haven't looked to see how much work that would be.
> 
> I have tried
>  	set view map; splot 'a.dat' with pm3d
> and
>  	plot 'a.dat' with image
> and it was the pm3d style which skipped the point, not the image style -- thus 
> the opposite observation.

Very interesting.  Those were not the test cases I tried.
For image plots I had in mind the examples in 'imageNaN.dem', 
which plot using the commands

plot  $matrixdata matrix with image  # NaN pixel is omitted
set view map
splot $matrixdata matrix with image  # NaN pixel is omitted


While for the pm3d plots I used the last plot in "pm3d.dem"
after modifying Dima's new harmean4() function to return NaN
when appropriate.  

You are absolutely right that the simpler non-matix
'plot with image' command also needs fixing.

> Isn't it gnuplot who does not read it properly?

It seems so.
Image data is read properly in matrix mode but not (it seems)
in non-matrix mode.

I do not understand why your pm3d example works but mine 
does not. From inspection of the code in pm3d.c I see no
special case for NaN pixel values, so how does it ever work?
I had been thinking that a new test would be needed,
like this:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -911,10 +914,11 @@ pm3d_plot(struct surface_points *this_pl
 
                        if (pm3d.direction != PM3D_DEPTH) {
                            if (color_from_rgbvar)
-                               set_rgbcolor(gray);
+                               set_rgbcolor((unsigned int)gray);
                            else
                                set_color(gray);
-                           filled_quadrangle(corners);
+                           if (!isnan(gray))
+                               filled_quadrangle(corners);
                        } else {
                            /* copy quadrangle */
                            quadrangle* qp = quadrangles + current_quadrangle;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Yet your example works even without this change.  How?
Clearly I need to stare at this some more.

	Ethan


> with
> 
> 0	0	0
> 0	1	-1
> 0	2	-4
> 0	3	-9
> 
> 1	0	1
> 1	1	0
> 1	2	-3
> 1	3	-8
> 
> 2	0	4
> 2	1	3
> 2	2	0
> 2	3	-5
> 
> 3	0	9
> 3	1	8
> 3	2	NaN
> 3	3	9
> 
> 
> ---
> Petr
> 

Re: [PATCH] New pm3d corners2color function

[Petr M. <mi...@ph...>]

> There is an option "set pm3d interpolate <xdelta>,<ydelta>" that
> produces smoother coloring subdividing each quadrangle into smaller
> quadrangles with individually calculated color values.  But these
> color values are always assign by linear interpolation.
>
> For color schemes c1/c2/c3/c4/mean this comes out equivalent to the
> same overall coloring applied to a finer grid of x,y values.  The
> finer the interpolation, the closer it comes to a true linear color
> gradient.
>
> However, for color schemes using the harmonic or geometric mean,
> the finer grid still results in a linear color gradient rather than
> the requested geometric or harmonic color variation.  Shouldn't the
> interpolation in these cases be some non-linear function?
> What function would that be?

Coordinates x, y can be interpolated linearly, but the colour coords can 
follow arithmentic, geometric or harmonic mean.

---
Petr

Re: [PATCH] New pm3d corners2color function

[Petr M. <mi...@ph...>]

> However, the pm3d code currently treats NaN as if it were zero anyhow,
> so as a practical matter the plot would not come out any different.
>
> The "with image" plot modes recognize NaN and do not draw the corresponding
> rectangular pixel.  Should we make pm3d do the same?
> I haven't looked to see how much work that would be.

Isn't it gnuplot who does not read it properly?
I have tried
 	set view map; splot 'a.dat' with pm3d
and
 	plot 'a.dat' with image
with

0	0	0
0	1	-1
0	2	-4
0	3	-9

1	0	1
1	1	0
1	2	-3
1	3	-8

2	0	4
2	1	3
2	2	0
2	3	-5

3	0	9
3	1	8
3	2	NaN
3	3	9

and it was the pm3d style which skipped the point, not the image style -- thus 
the opposite observation.

---
Petr

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Dima K. <gn...@di...>]

> On Sat, 29 Sep 2012 17:07:51 -0700
> Ethan Merritt <merritt@u.washington.edu> wrote:
>
> On Saturday, 29 September 2012, Dima Kogan wrote:
> >
> > 5. Adding default window size to the inboard x11 driver so that the 'terminal
> >    xlib' produces plots that have decent defaults when sent to the outboard
> >    driver manually. I'll do this.
>
>   OK.  It's not just xlib, however.  I think (not 100% sure) that the same 
>   problem arises whenever (ipc_back_fd == IPC_BACK_UNUSABLE), e.g. x11 output
>   from a script run non-interactively.

Attached is a patch to address this.

Code style and emacs

[<gn...@di...>]

Hi all.

How much do we care about consistent indentation style in the code? If we care
at all, it'd be good to include a .dir-locals.el file in the root directory in
the repo, so that emacs users get the "right" styling automatically. I'm
attaching a first pass at such a file. Not completely sure if this represents
the desired style fully, but it's a good first pass.

dima

Re: [PATCH] New pm3d corners2color function

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

On Thursday, 04 October 2012, Clement Law wrote:
> I've written a small patch[a] that adds a harmonic mean function[1] to
> pm3d corners2color. 
> 
> set pm3d corners2color harmean
> 
> The reason why I added another 'mean' function is to complete the set.
> Gnuplot at the moment as two of the three 'pythagorean means'[2]. The
> harmonic mean is useful as it can offer a truer sense of the average.
> See this physics example [3].
> 
> Clement Law

I have a related question.

There is an option "set pm3d interpolate <xdelta>,<ydelta>" that 
produces smoother coloring subdividing each quadrangle into smaller
quadrangles with individually calculated color values.  But these
color values are always assign by linear interpolation.

For color schemes c1/c2/c3/c4/mean this comes out equivalent to the 
same overall coloring applied to a finer grid of x,y values.  The
finer the interpolation, the closer it comes to a true linear color
gradient.

However, for color schemes using the harmonic or geometric mean,
the finer grid still results in a linear color gradient rather than
the requested geometric or harmonic color variation.  Shouldn't the
interpolation in these cases be some non-linear function?
What function would that be?

	Ethan

Re: [PATCH] New pm3d corners2color function

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

On Friday, 05 October 2012, pl...@pi... wrote:
> On 10/04/12 16:37, Clement Law wrote:
> > One question I have is that the harmonic mean is not defined for
> > numbers less than or equal to 0. Should I have harmean4() return 0 in
> > these cases?
> >
> > Clement Law
> 
> If the value is not defined then it should probably return NaN rather 
> than zero , which would be an incorrect result.
> 
> Presumably physical data where this is the appropriate mean would only 
> go zero or negative if there was an error in the data.
> 
> Thanks, Peter.

I agree.

However, the pm3d code currently treats NaN as if it were zero anyhow,
so as a practical matter the plot would not come out any different.

The "with image" plot modes recognize NaN and do not draw the corresponding
rectangular pixel.  Should we make pm3d do the same?
I haven't looked to see how much work that would be.

	Ethan

Re: [PATCH] New pm3d corners2color function

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

On 10/04/12 16:37, Clement Law wrote:
> One question I have is that the harmonic mean is not defined for
> numbers less than or equal to 0. Should I have harmean4() return 0 in
> these cases?
>
> I hope it's acceptable, I've never written a patch for any open source
> software before.
>
> Clement Law

If the value is not defined then it should probably return NaN rather 
than zero , which would be an incorrect result.

Presumably physical data where this is the appropriate mean would only 
go zero or negative if there was an error in the data.

I can see that this mean would be a useful addition.

Thanks, Peter.