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

Re: Demo! (was: Additional smoothing algorithm)

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

On Monday 12 May 2008 15:08, Daniel Farrell wrote:
> Hello,
> 
> This is a great facility, well done! This is very useful for people,  
> like me, that do Monte-Carlo simulations. Now after all that hard  
> work, here come the bit where people ask for improvements! I was  
> thinking...
> 
> ...it would be very useful, when plotting 3D data, to have projection  
> on the back walls of the splot. For example, if I have some  
> experimental points in 3D space which I think should be roughly follow  
> a Gaussian distribution. I could make some histogram projection on to  
> the back wall (xz-plane) which would bin all y points. A similar  
> histogram could be bin the x and z points and project on to the yz and  
> zy plane, respectively.
> 
> Having said that, it might be a bit complicated to mix 2D and 3D plots  
> in this way. Maybe, this would be easily achieved simply as a 2D plot.  
> i.e. 3D data goes in and a 2D projection along some specified axis  
> come out as a histogram.

It can be done, but it takes multiple steps:

1) Plot the X and Y projections as 2D plots.
   Make sure the plot borders are of zero width (i.e. the plot fills
   the image). You can do this in the cvs version by using the new
   commands  "set lmargin screen 0"  etc.

2) Make the 3D plot as a composite in which the data itself is plotted
   in 3D, and the previous 2D projections are read back in using
   "with image" and mapped onto the side walls of the view box.


	Ethan

 
> Dan.
> 
> 
> On 12 May 2008, at 05:25, Philipp K. Janert wrote:
> >
> > I have thrown a quick demo up on my website, to
> > show what this algorithm does:
> > 	http://philipp-janert.com/cumulative/
> >
> > Best,
> >
> > 		Ph.
> >
> >
> > On Sunday 11 May 2008 20:44, Philipp K. Janert wrote:
> >> I have developed some code for a new smoothing
> >> algorithm, which adds some functionality to gnuplot
> >> which I have long been desperate for: a way to plot
> >> cumulative distribution functions directly from data.
> >>
> >> The new algorithm is similar to (and built on top of)
> >> "smooth frequency". Like "smooth frequency", it
> >> sorts data points in ascending order of x-values, but
> >> then replaces each y-value with the cumulative sum
> >> of all y-values to the left of the current data point.
> >>
> >> I have submitted the code as patch 1962130.
> >>
> >> Please take a look and tell me what you think. The
> >> changes are small and very well localized.
> >>
> >> Best,
> >>
> >> 		Ph.
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save  
> > $100.
> > Use priority code J8TL2D2.
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry       Regular Mail: Mailstop 357742
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: Demo! (was: Additional smoothing algorithm)

[Daniel F. <boy...@gm...>]

Hello,

This is a great facility, well done! This is very useful for people,  
like me, that do Monte-Carlo simulations. Now after all that hard  
work, here come the bit where people ask for improvements! I was  
thinking...

...it would be very useful, when plotting 3D data, to have projection  
on the back walls of the splot. For example, if I have some  
experimental points in 3D space which I think should be roughly follow  
a Gaussian distribution. I could make some histogram projection on to  
the back wall (xz-plane) which would bin all y points. A similar  
histogram could be bin the x and z points and project on to the yz and  
zy plane, respectively.

Having said that, it might be a bit complicated to mix 2D and 3D plots  
in this way. Maybe, this would be easily achieved simply as a 2D plot.  
i.e. 3D data goes in and a 2D projection along some specified axis  
come out as a histogram.

Dan.


On 12 May 2008, at 05:25, Philipp K. Janert wrote:
>
> I have thrown a quick demo up on my website, to
> show what this algorithm does:
> 	http://philipp-janert.com/cumulative/
>
> Best,
>
> 		Ph.
>
>
> On Sunday 11 May 2008 20:44, Philipp K. Janert wrote:
>> I have developed some code for a new smoothing
>> algorithm, which adds some functionality to gnuplot
>> which I have long been desperate for: a way to plot
>> cumulative distribution functions directly from data.
>>
>> The new algorithm is similar to (and built on top of)
>> "smooth frequency". Like "smooth frequency", it
>> sorts data points in ascending order of x-values, but
>> then replaces each y-value with the cumulative sum
>> of all y-values to the left of the current data point.
>>
>> I have submitted the code as patch 1962130.
>>
>> Please take a look and tell me what you think. The
>> changes are small and very well localized.
>>
>> Best,
>>
>> 		Ph.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Patch 1757226 : probability scaling and axes

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

On Sunday 11 May 2008 20:48, Philipp K. Janert wrote:
> 
> I took a look at an older patch 1757226 (probability 
> scaling and axes).
> 
> I like the idea a lot, but the patch is large and a bit
> older. I am also not sure how "complete" the patch
> is in its current form - the "todo" list is a bit lengthy.
> 
> Has somebody else taken a look at it? Is James (the
> original submitter) still around to help get it in line
> with the current (4.3) devel version of gnuplot?

I would really like to see this implemented in the general form
mentioned on the TODO list. That is, I want a mechanism for mapping
an arbitrary monotonic function f(x) onto a display axis.
Both log(x) and probability(x) could become special cases of this
general code rather than being separate parallel code paths.

Furthermore, this would present an excuse^H^H^Hopportunity to
re-work how data values are stored internally.  Right now setting
log-scaling on an axis causes the corresponding data coordinate to
be transformed and stored as the log.  This creates great headaches
if you want to toggle the log-scaling and redraw the plot from the
data previously read in.  I think it would be much cleaner and more
flexible to store the original coordinate value on input, and only
apply the log- or other scaling during plot generation. 


-- 
Ethan A Merritt

Patch 1757226 : probability scaling and axes

[Philipp K. J. <ja...@ie...>]

I took a look at an older patch 1757226 (probability 
scaling and axes).

I like the idea a lot, but the patch is large and a bit
older. I am also not sure how "complete" the patch
is in its current form - the "todo" list is a bit lengthy.

Has somebody else taken a look at it? Is James (the
original submitter) still around to help get it in line
with the current (4.3) devel version of gnuplot?

Best,

		Ph.

Demo! (was: Additional smoothing algorithm)

[Philipp K. J. <ja...@ie...>]

I have thrown a quick demo up on my website, to
show what this algorithm does:
	http://philipp-janert.com/cumulative/

Best,

		Ph.


On Sunday 11 May 2008 20:44, Philipp K. Janert wrote:
> I have developed some code for a new smoothing
> algorithm, which adds some functionality to gnuplot
> which I have long been desperate for: a way to plot
> cumulative distribution functions directly from data.
>
> The new algorithm is similar to (and built on top of)
> "smooth frequency". Like "smooth frequency", it
> sorts data points in ascending order of x-values, but
> then replaces each y-value with the cumulative sum
> of all y-values to the left of the current data point.
>
> I have submitted the code as patch 1962130.
>
> Please take a look and tell me what you think. The
> changes are small and very well localized.
>
> Best,
>
> 		Ph.

Re: Patch 1827826: dgrid3d

[Philipp K. J. <ja...@ie...>]

On Sunday 11 May 2008 20:58, Ethan A Merritt wrote:
> On Sunday 11 May 2008 20:40, Philipp K. Janert wrote:
> > I have dusted off patch 1827826 (more smoothing
> > algorithms for dgrid3d) and made it to work with the
> > current development version.
> >
> > Are there any objections to inclusion into the main
> > branch at this time?
>
> Could you summarize for us what tests you have run to confirm
> that it functions as advertised?

I have run the complete gnuplot unit-test suite
against it. ;-) 

I have taken some sample data set and tried
the new algorithms out on them and visually
inspected the results. The "gnu-valley" mini
data set from the gnuplot documentation is
pretty informative.

>
> Does it gracefully handle missing or non-uniform data?

Yes. Both of these are features that dgrid3d itself provides,
and which I have not modified. I merely have added some 
additional smoothing kernels (and syntax and options to
manage them).

>
> Should it come with guidance or warnings about which function
> is suitable for what data?

I don't think this is really necessary. The Gaussian 
kernel is probably the most general, all-purpose 
kernel in this patch. I don't want to patronize the
reader, but we can include a sentence like "Unless
you have special needs, the Gaussian kernel is
likely to give satisfactory results."

>
> Maybe a demo like the one on the Wikipedia page at
> http://en.wikipedia.org/wiki/Window_function

I can provide some demos for inclusion into the demo/
folder. I think that is a good idea.

Best,

		Ph.

Re: Patch 1827826: dgrid3d

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

On Sunday 11 May 2008 20:40, Philipp K. Janert wrote:
> 
> I have dusted off patch 1827826 (more smoothing 
> algorithms for dgrid3d) and made it to work with the
> current development version.
> 
> Are there any objections to inclusion into the main
> branch at this time?

Could you summarize for us what tests you have run to confirm
that it functions as advertised?

Does it gracefully handle missing or non-uniform data?

Should it come with guidance or warnings about which function
is suitable for what data?

Maybe a demo like the one on the Wikipedia page at
http://en.wikipedia.org/wiki/Window_function

-- 
Ethan A Merritt

Additional smoothing algorithm

[Philipp K. J. <ja...@ie...>]

I have developed some code for a new smoothing
algorithm, which adds some functionality to gnuplot
which I have long been desperate for: a way to plot
cumulative distribution functions directly from data.

The new algorithm is similar to (and built on top of)
"smooth frequency". Like "smooth frequency", it 
sorts data points in ascending order of x-values, but
then replaces each y-value with the cumulative sum 
of all y-values to the left of the current data point. 
 
I have submitted the code as patch 1962130.

Please take a look and tell me what you think. The 
changes are small and very well localized.

Best,

		Ph.

Patch 1827826: dgrid3d

[Philipp K. J. <ja...@ie...>]

I have dusted off patch 1827826 (more smoothing 
algorithms for dgrid3d) and made it to work with the
current development version.

Are there any objections to inclusion into the main
branch at this time?

Best,

		Ph.

Re: texinfo errors in 4.2-cvs

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

On Monday 28 April 2008 00:06, Petr Mikulik wrote:
> In the current 4.2-cvs, "make install" proceeds with the errors below. It's 
> strang because there are "?set origin" and "?origin" in gnuplot.doc.

For some reason the doc->texi process has replaced the key word "origin"
with "origin_".  I don't know why.
Editing gnuplot.texi
	%s/origin_/origin/
followed by 'make gnuplot.info'  works

 
> ---
> 
> ../mkinstalldirs /usr/local/share/gnuplot/4.2
> 
> /usr/bin/install -c -m 644 gnuplot.gih 
> 
> /usr/local/share/gnuplot/4.2/gnuplot.gih
> 
> /bin/sh /tmp/gnuplot42/missing --run makeinfo 
> -I. ./gnuplot.texi --no-split --output=gnuplot.info
> 
> ./gnuplot.texi:10550: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:10044: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:9702: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:9481: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:9470: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:9461: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:9444: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:9442: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:7382: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:4840: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:4821: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:4810: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:3430: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> ./gnuplot.texi:3102: Cross reference to nonexistent node `origin' (perhaps 
> incorrect sectioning?).
> 
> makeinfo: Removing output file `gnuplot.info' due to errors; use --force to 
> preserve.
> 
> make[1]: *** [gnuplot.info] Error 1
> 
> make[1]: Leaving directory `/tmp/gnuplot42/docs'
> 
> make: *** [install-recursive] Error 1
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry       Regular Mail: Mailstop 357742
Health Sciences Building
University of Washington - Seattle WA 98195-7742

texinfo errors in 4.2-cvs

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

In the current 4.2-cvs, "make install" proceeds with the errors below. It's 
strang because there are "?set origin" and "?origin" in gnuplot.doc.

---

../mkinstalldirs /usr/local/share/gnuplot/4.2

/usr/bin/install -c -m 644 gnuplot.gih 

/usr/local/share/gnuplot/4.2/gnuplot.gih

/bin/sh /tmp/gnuplot42/missing --run makeinfo 
-I. ./gnuplot.texi --no-split --output=gnuplot.info

./gnuplot.texi:10550: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:10044: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:9702: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:9481: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:9470: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:9461: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:9444: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:9442: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:7382: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:4840: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:4821: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:4810: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:3430: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).
./gnuplot.texi:3102: Cross reference to nonexistent node `origin' (perhaps 
incorrect sectioning?).

makeinfo: Removing output file `gnuplot.info' due to errors; use --force to 
preserve.

make[1]: *** [gnuplot.info] Error 1

make[1]: Leaving directory `/tmp/gnuplot42/docs'

make: *** [install-recursive] Error 1

Re: "set term" vs "set terminal"

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

On Thu, 17 Apr 2008, Allin Cottrell wrote:

> On Thu, 17 Apr 2008, Hans-Bernhard Bröker wrote:
> > 
> > I might succeed in breaking gnuplot on purpose to have that 
> > effect, but I find it extremely hard to believe that anything 
> > like that could ever, possibly, happen by accident.  It's more 
> > likely that the user in question was either pulling your leg, or 
> > hallucinating.

Well, it turns out that whatever problem the user was having with 
the gretl/gnuplot connection, "set term " was not really the 
issue.  Not surprising, but that is what he claimed at first.

Allin Cottrell

Re: "set term" vs "set terminal"

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

On Thu, 17 Apr 2008, Hans-Bernhard Bröker wrote:

> Allin Cottrell wrote:
> > Gretl writes, e.g., "set term png" when calling gnuplot.
> 
> Care dropping a hint what "Gretl" is, or why we might want to 
> know?

Sorry, I thought I'd mentioned gretl a couple of times on this 
list before, but maybe not.  It's an open-source econometrics 
program which calls gnuplot for generating graphs, much as octave 
does. http://gretl.sourceforge.net/

> > We've recently had a report from a user who says his copy of 
> > gnuplot 4.2 won't accept "set term png" (but will accept "set 
> > terminal png").
> 
> I find that completely unbelievable.  On what platform did that 
> supposedly happen, and how/where did he acquire that copy of 
> gnuplot?

I'm told this was open on OpenSuse 10.2 i586.  I don't know the 
source of the copy of gnuplot but I suppose it was an OpenSuse 
rpm.

> > Can anyone think of circumstances where there might be a 
> > problem using the abbreviation, or must this be a broken build 
> > of gnuplot?
> 
> I might succeed in breaking gnuplot on purpose to have that 
> effect, but I find it extremely hard to believe that anything 
> like that could ever, possibly, happen by accident.  It's more 
> likely that the user in question was either pulling your leg, or 
> hallucinating.

It's a bit late for April Fooling.  But it is indeed puzzling.

Allin Cottrell

Re: "set term" vs "set terminal"

[Hans-Bernhard B. <HBB...@t-...>]

Allin Cottrell wrote:
> Gretl writes, e.g., "set term png" when calling gnuplot.

Care dropping a hint what "Gretl" is, or why we might want to know?

> We've recently had a report from a user who says his copy of 
> gnuplot 4.2 won't accept "set term png" (but will accept "set 
> terminal png").

I find that completely unbelievable.  On what platform did that 
supposedly happen, and how/where did he acquire that copy of gnuplot?

> Can anyone think of circumstances where there might be a problem 
> using the abbreviation, or must this be a broken build of gnuplot?

I might succeed in breaking gnuplot on purpose to have that effect, but 
I find it extremely hard to believe that anything like that could ever, 
possibly, happen by accident.  It's more likely that the user in 
question was either pulling your leg, or hallucinating.

"set term" vs "set terminal"

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

Gretl writes, e.g., "set term png" when calling gnuplot.

We've recently had a report from a user who says his copy of 
gnuplot 4.2 won't accept "set term png" (but will accept "set 
terminal png").

I just tried building gnuplot 4.2.3 myself and had no problem 
with "set term".

Can anyone think of circumstances where there might be a problem 
using the abbreviation, or must this be a broken build of gnuplot?


Thanks.

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

Re: key box spacing defects (jpeg)

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

On Sun, 13 Apr 2008 20:45:14 +0200, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Sunday 13 April 2008 11:26, Ethan A Merritt wrote:
>> On Sunday 13 April 2008 01:55, you wrote:
>> > So it appears there is an svg specific issue but also something  
>> producing
>> > spacing on the other plots you can see in the link in both png and  
>> jpeg.
>>
>> Sorry, I still don't see anything unusual about any of those plots
>> including the svg ones.  Perhaps you could include a screen-capture
>> of how the svg looks in your viewer?
>
> I attach a screen capture of what your svg plot looks like when
> viewed here.
>

Now how about the non-svg terminals:

http://piments.com/panel/150tank-txR.jpeg

we see a similar exagerated left spacing. This is gnuplot output so not  
dependant on rendition outside the context of gnuplot in creating it.

This makes me think that something is causing gnuplot to allocate too much  
space for the text on my system in creating the plot rather than a display  
time difference due to svg libs/fonts.

What do you make of that?

Thx.

Re: key box spacing defects

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

On Sunday 13 April 2008 11:26, Ethan A Merritt wrote:
> On Sunday 13 April 2008 01:55, you wrote:
> > So it appears there is an svg specific issue but also something producing  
> > spacing on the other plots you can see in the link in both png and jpeg.
> 
> Sorry, I still don't see anything unusual about any of those plots
> including the svg ones.  Perhaps you could include a screen-capture
> of how the svg looks in your viewer?

I attach a screen capture of what your svg plot looks like when
viewed here.

-- 
Ethan A Merritt

Fwd: Re: key box spacing defects

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

Please ignore this post which contains incorrect info and refer to my
later one.

Sorry for the bad post.

/Peter

On Sun, 13 Apr 2008 09:58:03 +0200, <pl...@pi...> wrote:

> On Sun, 13 Apr 2008 03:06:27 +0200, Ethan A Merritt
> <merritt@u.washington.edu> wrote:
>
>> On Saturday 12 April 2008 17:38, pl...@pi... wrote:
>>> Hi,
>>>
>>> a minor issue but worth fixing at some stage.
>>>
>>> I need to get the key box as tight as possible to prevent it
>>> over-running
>>> my plots. This must surely be quite a common concern.
>>>
>>> In trying to reduce it I notice that there are one or two extras space
>>> characters before each legend's text. The space after the line sample
>>> seems a reasonable size but the left border space is about three times
>>> bigger. This is wasted space and a visual imbalance.
>>
>> I can't seem to reproduce this problem.
>> Please tell us the exact version of gnuplot you are using,
>> and the exact "set terminal" command including the font.
>>
>> The one case I know of that behaves somewhat like this is when you
>> have an enhanced text string as a plot title.  Gnuplot over-estimates
>> the length of the title because of the enhanced text mark-up characters.
>> You can adjust this by using the "width" keyword to "set key box".
>>
>>
>>
>>
>>> Also there seems to be no top margin. The "l" in plot of my first line
>>> actually touches the box (with set key box).
>>>
>>> If someone works on this part of gnuplot it maybe a thing to tidy up.
>>>
>>> A consistant border all the way round would be nice. Maybe with an
>>> option
>>> border width to control it like is possible with vertical line spacing.
>>
>
> Hi,
>
> I am running CVS gnuplot rebuild at begining April 08.
>
> I noticed this on svg output and looking back over archived plots (done
> with 6 mth old cvs) I note that png seems exactly the same layout:
> http://piments.com/panel/images/
>
>
> however I have a jpeg (prob cvs march 07) that has no left margin and the
> first letter of the longest label touches the box.
>
> This one has a rather large left margin , is there a minimum default  
> width
> at play here?
> http://piments.com/panel/150tank-txW.svg
> cf http://piments.com/panel/150tank-txI.jpeg
> cf file://localhost/tmpd/img/panel/150tank-tx6.png
>
> Looking over many outputs over this period of time I see many different
> behaviours. For example this svg which has zero top and left margin but
> reasonable right and bottom. This has not explicit key commands in the
> source file.
>
> http://piments.com/panel/trans-fn.svg
>
>
> Feel free to parouse http://piments.com/panel and
> http://piments.com/panel/images there are a variety of output formats
> dating from this period. All the 150tank* files are essentially the same
> gnuplot source as far as the box goes. There are a number of different
> plot titles in plot commands , none of which have any leading spaces.
>
> The only key commands are:
>
> set key box
> set key top right
>
> HTH.
> /Peter.
>

Re: key box spacing defects

[<so...@pi...>]

Please ignore this post which contains incorrect info and refer to my  
later one.

Sorry for the bad post.

/Peter

On Sun, 13 Apr 2008 09:58:03 +0200, <pl...@pi...> wrote:

> On Sun, 13 Apr 2008 03:06:27 +0200, Ethan A Merritt
> <merritt@u.washington.edu> wrote:
>
>> On Saturday 12 April 2008 17:38, pl...@pi... wrote:
>>> Hi,
>>>
>>> a minor issue but worth fixing at some stage.
>>>
>>> I need to get the key box as tight as possible to prevent it
>>> over-running
>>> my plots. This must surely be quite a common concern.
>>>
>>> In trying to reduce it I notice that there are one or two extras space
>>> characters before each legend's text. The space after the line sample
>>> seems a reasonable size but the left border space is about three times
>>> bigger. This is wasted space and a visual imbalance.
>>
>> I can't seem to reproduce this problem.
>> Please tell us the exact version of gnuplot you are using,
>> and the exact "set terminal" command including the font.
>>
>> The one case I know of that behaves somewhat like this is when you
>> have an enhanced text string as a plot title.  Gnuplot over-estimates
>> the length of the title because of the enhanced text mark-up characters.
>> You can adjust this by using the "width" keyword to "set key box".
>>
>>
>>
>>
>>> Also there seems to be no top margin. The "l" in plot of my first line
>>> actually touches the box (with set key box).
>>>
>>> If someone works on this part of gnuplot it maybe a thing to tidy up.
>>>
>>> A consistant border all the way round would be nice. Maybe with an
>>> option
>>> border width to control it like is possible with vertical line spacing.
>>
>
> Hi,
>
> I am running CVS gnuplot rebuild at begining April 08.
>
> I noticed this on svg output and looking back over archived plots (done
> with 6 mth old cvs) I note that png seems exactly the same layout:
> http://piments.com/panel/images/
>
>
> however I have a jpeg (prob cvs march 07) that has no left margin and the
> first letter of the longest label touches the box.
>
> This one has a rather large left margin , is there a minimum default  
> width
> at play here?
> http://piments.com/panel/150tank-txW.svg
> cf http://piments.com/panel/150tank-txI.jpeg
> cf file://localhost/tmpd/img/panel/150tank-tx6.png
>
> Looking over many outputs over this period of time I see many different
> behaviours. For example this svg which has zero top and left margin but
> reasonable right and bottom. This has not explicit key commands in the
> source file.
>
> http://piments.com/panel/trans-fn.svg
>
>
> Feel free to parouse http://piments.com/panel and
> http://piments.com/panel/images there are a variety of output formats
> dating from this period. All the 150tank* files are essentially the same
> gnuplot source as far as the box goes. There are a number of different
> plot titles in plot commands , none of which have any leading spaces.
>
> The only key commands are:
>
> set key box
> set key top right
>
> HTH.
> /Peter.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: key box spacing defects

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

On Sun, 13 Apr 2008 03:06:27 +0200, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Saturday 12 April 2008 17:38, pl...@pi... wrote:
>> Hi,
>>
>> a minor issue but worth fixing at some stage.
>>
>> I need to get the key box as tight as possible to prevent it  
>> over-running
>> my plots. This must surely be quite a common concern.
>>
>> In trying to reduce it I notice that there are one or two extras space
>> characters before each legend's text. The space after the line sample
>> seems a reasonable size but the left border space is about three times
>> bigger. This is wasted space and a visual imbalance.
>
> I can't seem to reproduce this problem.
> Please tell us the exact version of gnuplot you are using,
> and the exact "set terminal" command including the font.
>
Hi,

currently using CVS build early April 2008. Other plots showing similar  
defects date back a year and use cvs from either march or sept 07. I dont  
see any notable change due to date.

The output is mainly svg but you can see the left margin issue on png and  
jpeg during this period.
http://www.piments.com/panel

All the 150tank* files here produced by basically the same gnuplot file as  
far as key box is concerned.

An interesting example is :
http://piments.com/panel/trans-fn.svg

Also a variant on the same source this shows no padding. I have looked  
into experimenting with this and find the lenghts of the plot titles seems  
to be a key factor.

If I mod this source and change nothing else I start to get margins.

plot Th4(RR1(x)) t "Rf=3k3" \
,Th4(RR2(x)) t "short Rf=4k7" \
,Th4(RR3(x)) t "long energy Rf=6k8" \
,Th4(RR7(x)) t "Energy Rf=15k"

This does not reproduce in png/jpeg in this particular test , just svg. I  
viewed the file in Opera / ffox / inkscape , all gave the same rendition.

So it appears there is an svg specific issue but also something producing  
spacing on the other plots you can see in the link in both png and jpeg.

HTH.



> The one case I know of that behaves somewhat like this is when you
> have an enhanced text string as a plot title.  Gnuplot over-estimates
> the length of the title because of the enhanced text mark-up characters.
> You can adjust this by using the "width" keyword to "set key box".
>
>
  No use of enhanced here.

>
>
>> Also there seems to be no top margin. The "l" in plot of my first line
>> actually touches the box (with set key box).
>>
>> If someone works on this part of gnuplot it maybe a thing to tidy up.
>>
>> A consistant border all the way round would be nice. Maybe with an  
>> option
>> border width to control it like is possible with vertical line spacing.
>

Re: key box spacing defects

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

On Sun, 13 Apr 2008 03:06:27 +0200, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Saturday 12 April 2008 17:38, pl...@pi... wrote:
>> Hi,
>>
>> a minor issue but worth fixing at some stage.
>>
>> I need to get the key box as tight as possible to prevent it  
>> over-running
>> my plots. This must surely be quite a common concern.
>>
>> In trying to reduce it I notice that there are one or two extras space
>> characters before each legend's text. The space after the line sample
>> seems a reasonable size but the left border space is about three times
>> bigger. This is wasted space and a visual imbalance.
>
> I can't seem to reproduce this problem.
> Please tell us the exact version of gnuplot you are using,
> and the exact "set terminal" command including the font.
>
> The one case I know of that behaves somewhat like this is when you
> have an enhanced text string as a plot title.  Gnuplot over-estimates
> the length of the title because of the enhanced text mark-up characters.
> You can adjust this by using the "width" keyword to "set key box".
>
>
>
>
>> Also there seems to be no top margin. The "l" in plot of my first line
>> actually touches the box (with set key box).
>>
>> If someone works on this part of gnuplot it maybe a thing to tidy up.
>>
>> A consistant border all the way round would be nice. Maybe with an  
>> option
>> border width to control it like is possible with vertical line spacing.
>

Hi,

I am running CVS gnuplot rebuild at begining April 08.

I noticed this on svg output and looking back over archived plots (done  
with 6 mth old cvs) I note that png seems exactly the same layout:
http://piments.com/panel/images/


however I have a jpeg (prob cvs march 07) that has no left margin and the  
first letter of the longest label touches the box.

This one has a rather large left margin , is there a minimum default width  
at play here?
http://piments.com/panel/150tank-txW.svg
cf http://piments.com/panel/150tank-txI.jpeg
cf file://localhost/tmpd/img/panel/150tank-tx6.png

Looking over many outputs over this period of time I see many different  
behaviours. For example this svg which has zero top and left margin but  
reasonable right and bottom. This has not explicit key commands in the  
source file.

http://piments.com/panel/trans-fn.svg


Feel free to parouse http://piments.com/panel and  
http://piments.com/panel/images there are a variety of output formats  
dating from this period. All the 150tank* files are essentially the same  
gnuplot source as far as the box goes. There are a number of different  
plot titles in plot commands , none of which have any leading spaces.

The only key commands are:

set key box
set key top right

HTH.
/Peter.

Re: key box spacing defects

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

On Saturday 12 April 2008 17:38, pl...@pi... wrote:
> Hi,
> 
> a minor issue but worth fixing at some stage.
> 
> I need to get the key box as tight as possible to prevent it over-running  
> my plots. This must surely be quite a common concern.
> 
> In trying to reduce it I notice that there are one or two extras space  
> characters before each legend's text. The space after the line sample  
> seems a reasonable size but the left border space is about three times  
> bigger. This is wasted space and a visual imbalance.

I can't seem to reproduce this problem.
Please tell us the exact version of gnuplot you are using,
and the exact "set terminal" command including the font.

The one case I know of that behaves somewhat like this is when you
have an enhanced text string as a plot title.  Gnuplot over-estimates
the length of the title because of the enhanced text mark-up characters.
You can adjust this by using the "width" keyword to "set key box".




> Also there seems to be no top margin. The "l" in plot of my first line  
> actually touches the box (with set key box).
> 
> If someone works on this part of gnuplot it maybe a thing to tidy up.
> 
> A consistant border all the way round would be nice. Maybe with an option  
> border width to control it like is possible with vertical line spacing.

-- 
Ethan A Merritt

key box spacing defects

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

Hi,

a minor issue but worth fixing at some stage.

I need to get the key box as tight as possible to prevent it over-running  
my plots. This must surely be quite a common concern.

In trying to reduce it I notice that there are one or two extras space  
characters before each legend's text. The space after the line sample  
seems a reasonable size but the left border space is about three times  
bigger. This is wasted space and a visual imbalance.

Also there seems to be no top margin. The "l" in plot of my first line  
actually touches the box (with set key box).

If someone works on this part of gnuplot it maybe a thing to tidy up.

A consistant border all the way round would be nice. Maybe with an option  
border width to control it like is possible with vertical line spacing.

Thx.

Re: Naming of gnuplot binaries which are native to windows including the console mode one built by Michael

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

Hello

--- Hans-Bernhard Br醇rker <HBB...@t-...> wrote:

> Tatsuro MATSUOKA wrote:
> > Hello Petr Mikulik 
> > 
> > I would like to confirm what you will proceed gnuplot native to windows.
> > 
> >> wgnuplot
> >> wgnuplot_pipes
> >> pgnuplot
> > 
> > wgnuplot -> Windows native original console gnuplot with GUI menu. 
> 
> This description is confusing.  wgnuplot is not a "console gnuplot". 
> It's the MS Windows GUI version.  In the context of MS Windows, 
> "console" is the opposite of "GUI".

You are right. Sorry for my poor writing.  
'An interactive terminal with GUI Menu'
Is this representation OK?
 
> The text window provided by wgnuplot is not a console --- it's what we 
> use because we _don't_ have a console.
> 
> > pgnuplot -> Console mode gnuplot for windows from cmd  prompt (and from proxy console software
> like 
> > console2).  Of course the pipe also can be used for bidirectional unlike current pgnuplot.
> 
> I'd really prefer to have this named 'gnuplot'.  'pgnuplot' is the name 
> of a very peculiar program.  Using the same name for a program that 
> works in an entirely different way is guaranteed to confuse people.
> 
Personally in my mind, I also think so.
Pherhaps Petr stress on the comatibility to current softwarea on windows platform.

Regards
Tatsuro


--------------------------------------
GANBARE! NIPPON! Win your ticket to Olympic Games 2008.
http://pr.mail.yahoo.co.jp/ganbare-nippon/

Re: Naming of gnuplot binaries which are native to windows including the console mode one built by Michael

[Hans-Bernhard B. <HBB...@t-...>]

Tatsuro MATSUOKA wrote:
> Hello Petr Mikulik 
> 
> I would like to confirm what you will proceed gnuplot native to windows.
> 
>> wgnuplot
>> wgnuplot_pipes
>> pgnuplot
> 
> wgnuplot -> Windows native original console gnuplot with GUI menu. 

This description is confusing.  wgnuplot is not a "console gnuplot". 
It's the MS Windows GUI version.  In the context of MS Windows, 
"console" is the opposite of "GUI".

The text window provided by wgnuplot is not a console --- it's what we 
use because we _don't_ have a console.

> pgnuplot -> Console mode gnuplot for windows from cmd  prompt (and from proxy console software like 
> console2).  Of course the pipe also can be used for bidirectional unlike current pgnuplot.

I'd really prefer to have this named 'gnuplot'.  'pgnuplot' is the name 
of a very peculiar program.  Using the same name for a program that 
works in an entirely different way is guaranteed to confuse people.