gnuplot-beta

Suggestions for 5.0: Margin (and Key)

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

All -

Before it is too-too late, I wanted to put 
forward thre small suggestions concerning 
the margins and the key.


1) Naming of margins
The naming of the margin options scatters 
them around in any alphabetical listing of
options. I wonder whether we could add 
alternative names, that put the location 
last (not first) - similar to what is done
in CSS: margin-top, margin-bottom, etc.

This could be done in addition to the current
naming and so preserve backwards compatibility.

Alternatively (and more ambitiously) one could
treat the location of the margin as a sub-option,
like so:
	set margin top 5
and so on. This would (in principle) allow to
combine settings:
	set margin left right 5
but I am not sure how useful that would be.


2) Explicit display of margin value
Is there a way to show the actual margin value,
when the margin is computed automatically? 

Frequently, I find that I would like to adjust
the margin from its automatic value - but in 
order to do so, I have to find the ACTUAL value
first by trial and error. It would be much 
easier if the computed value was displayed, 
for example like so:
	show margin
	lmargin is computed automatically, currently 5
or similar.

(Another use case arises with multiplot, where I
am happy with the margin value chosen by one of
the plots, and now would like to fix both plots
to use that value. Again - currently, I have to
find the actual margin value by trial and error.)


3) Key position and offset
A very similar situation arises with the positioning
of the key. Frequently, I am happy with the automatic
positioning, but would like to adjust it slightly.

I can see two solutions for that: one is that 
	show key
would display the actual position of the margin (so
that this position, when given to "set key at ..."
would reproduce the previous plot), 
OR the introduction of an additional sub-option, 
"offset" to the "key" option, similar to what already
exists for xlabel, ylabel, and so on.


Any thoughts on either of these suggestions? 

Best,

		Ph.

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 13:01:02 Philipp K. Janert wrote:
> 
> All -
> 
> Before it is too-too late, I wanted to put 
> forward thre small suggestions concerning 
> the margins and the key.
> 
> 
> 1) Naming of margins
> The naming of the margin options scatters 
> them around in any alphabetical listing of
> options. I wonder whether we could add 
> alternative names, that put the location 
> last (not first) - similar to what is done
> in CSS: margin-top, margin-bottom, etc.

Where do you mean?
They are already collected together so far as "show margin"
output is concerned, or "help set margin" for that matter.

> Alternatively (and more ambitiously) one could
> treat the location of the margin as a sub-option,
> like so:
> 	set margin top 5
> and so on. This would (in principle) allow to
> combine settings:
> 	set margin left right 5
> but I am not sure how useful that would be.

Maybe just 
	set margins [l],[r],[t],[b]

I have wanted that from time to time.

> 2) Explicit display of margin value
> Is there a way to show the actual margin value,
> when the margin is computed automatically? 

You mean in screen coordinates?

    set lmargin at screen GPVAL_TERM_XMIN / GPVAL_TERM_XSIZE

and so on.

> 3) Key position and offset
> A very similar situation arises with the positioning
> of the key. Frequently, I am happy with the automatic
> positioning, but would like to adjust it slightly.
> 
> I can see two solutions for that: one is that 
> 	show key
> would display the actual position of the margin (so
> that this position, when given to "set key at ..."
> would reproduce the previous plot), 

See above.  These values can be retrieved from the GPVAL variables.

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

[Christoph B. <us...@be...>]

Zitat von Ethan A Merritt <sf...@us...>:

> On Wednesday, 18 June, 2014 13:01:02 Philipp K. Janert wrote:
>>
>>
>> 	set margin top 5
>> and so on. This would (in principle) allow to
>> combine settings:
>> 	set margin left right 5
>> but I am not sure how useful that would be.
>
> Maybe just
> 	set margins [l],[r],[t],[b]
>
> I have wanted that from time to time.

I would also like to see such a compact command for specifying all margins.

>
>> 2) Explicit display of margin value
>> Is there a way to show the actual margin value,
>> when the margin is computed automatically?
>
> You mean in screen coordinates?
>
>     set lmargin at screen GPVAL_TERM_XMIN / GPVAL_TERM_XSIZE
>
> and so on.

Unfortunately, that doesn't work properly for all terminals, see my  
bug report https://sourceforge.net/p/gnuplot/bugs/1291/

Christoph

Re: Suggestions for 5.0: Margin (and Key)

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

> > 1) Naming of margins
> > The naming of the margin options scatters 
> > them around in any alphabetical listing of
> > options. I wonder whether we could add 
> > alternative names, that put the location 
> > last (not first) - similar to what is done
> > in CSS: margin-top, margin-bottom, etc.
> 
> Where do you mean?
> They are already collected together so far as "show margin"
> output is concerned, or "help set margin" for that matter.

For instance in the reference manual...

> 
> > Alternatively (and more ambitiously) one could
> > treat the location of the margin as a sub-option,
> > like so:
> > 	set margin top 5
> > and so on. This would (in principle) allow to
> > combine settings:
> > 	set margin left right 5
> > but I am not sure how useful that would be.
> 
> Maybe just 
> 	set margins [l],[r],[t],[b]

That would be fine...

> 
> I have wanted that from time to time.
> 
> > 2) Explicit display of margin value
> > Is there a way to show the actual margin value,
> > when the margin is computed automatically? 
> 
> You mean in screen coordinates?
> 
>     set lmargin at screen GPVAL_TERM_XMIN / GPVAL_TERM_XSIZE
> 
> and so on.

I see. Yes, that would work. 

But I was actually thinking of a more direct
display, in the same coordinate system that 
"set margin" takes - in other words, using 
the current character position of the margin.

But I agree that the command above solves my
problem.

> 
> > 3) Key position and offset
> > A very similar situation arises with the positioning
> > of the key. Frequently, I am happy with the automatic
> > positioning, but would like to adjust it slightly.
> > 
> > I can see two solutions for that: one is that 
> > 	show key
> > would display the actual position of the margin (so
> > that this position, when given to "set key at ..."
> > would reproduce the previous plot), 
> 
> See above.  These values can be retrieved from the GPVAL variables.

What variables hold the key position? When I
do "show variables all", nothing seems appropriate.

> 
> 	Ethan
> 
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
> Solutions Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> 
> > > 1) Naming of margins
> > > The naming of the margin options scatters 
> > > them around in any alphabetical listing of
> > > options. I wonder whether we could add 
> > > alternative names, that put the location 
> > > last (not first) - similar to what is done
> > > in CSS: margin-top, margin-bottom, etc.
> > 
> > Where do you mean?
> > They are already collected together so far as "show margin"
> > output is concerned, or "help set margin" for that matter.
> 
> For instance in the reference manual...

Sorry - I'm not following you.
The reference manual has a section under 

Commands
   ->  Set
         -> Margin

i.e. the same as you get with "help set margin".

What are you asking for instead?

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:

> > > 3) Key position and offset
> > > A very similar situation arises with the positioning
> > > of the key. Frequently, I am happy with the automatic
> > > positioning, but would like to adjust it slightly.
> > > 
> > > I can see two solutions for that: one is that 
> > > 	show key
> > > would display the actual position of the margin (so
> > > that this position, when given to "set key at ..."
> > > would reproduce the previous plot), 
> > 
> > See above.  These values can be retrieved from the GPVAL variables.
> 
> What variables hold the key position? When I
> do "show variables all", nothing seems appropriate.

I meant that you can position the key box relative to the plot
border by using, e.g.

  set key top right at graph 0.98, graph 0.98

If you want to adjust that down to the individual pixel, you can
translate those coords using GPVAL_TERM_*

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wed, 18 Jun 2014 15:31:46 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> 
> > > > 3) Key position and offset
> > > > A very similar situation arises with the positioning
> > > > of the key. Frequently, I am happy with the automatic
> > > > positioning, but would like to adjust it slightly.
> > > > 
> > > > I can see two solutions for that: one is that 
> > > > 	show key
> > > > would display the actual position of the margin (so
> > > > that this position, when given to "set key at ..."
> > > > would reproduce the previous plot), 
> > > 
> > > See above.  These values can be retrieved from the GPVAL
> > > variables.
> > 
> > What variables hold the key position? When I
> > do "show variables all", nothing seems appropriate.
> 
> I meant that you can position the key box relative to the plot
> border by using, e.g.
> 
>   set key top right at graph 0.98, graph 0.98

But that's not what I mean! I know that I can place
the key arbitrarily - IFF I know, in absolute terms,
where I want it!

My use case is this: I want to use the automatically 
chosen position as starting point, and then modify it.
This could be done through an "offset" directive in
"set key", but it could also be done if I could read
out the currently chosen key position from some 
automatically set GPVAL variable. But none of the
GPVAL vars seems to refer to the current key position.

Or am I missing something?

> 
> If you want to adjust that down to the individual pixel, you can
> translate those coords using GPVAL_TERM_*
> 
> 	Ethan

Re: Suggestions for 5.0: Margin (and Key)

[sfeam <sf...@us...>]

On Wednesday, 18 June 2014 04:10:12 PM Jonathan Thornburg wrote:
> Philipp K. Janert wrote:
> > 3) Key position and offset
> > A very similar situation arises with the positioning
> > of the key. Frequently, I am happy with the automatic
> > positioning, but would like to adjust it slightly.
> > 
> > I can see two solutions for that: one is that 
> > 	show key
> > would display the actual position of the margin (so
> > that this position, when given to "set key at ..."
> > would reproduce the previous plot), 
> 
> Ethan A Merritt <sf...@us...> replied:
> : See above.  These values can be retrieved from the GPVAL
> : variables.
> 
> > What variables hold the key position? When I
> > do "show variables all", nothing seems appropriate.
> 
> : I meant that you can position the key box relative to the plot
> : border by using, e.g.
> : 
> :   set key top right at graph 0.98, graph 0.98
> 
> I've had the same problem as Philipp.  It usually strikes when I'm
> using the postscript terminal, where gnuplot doesn't know the actual
> width of the plot key.  I end up doing a fair bit of trial and error
> to determine either a "width" adjustment to, or an absolute position for,
> the plot key.
> 
> An example might make this clearer:  Consider the following two gnuplot
> scripts (which differ only in their "set key" lines & the names of their
> output files):
> 
> --- BEGIN #1
> set term postscript eps enhanced color solid 14
> set output 'key-demo.eps'
> 
> set key top left Left reverse samplen 2.5 spacing 1.333
> 
> set xrange [0:10]
> set yrange [-1:1]
> 
> plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
>      with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
>      (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
>      with lines linetype 1 linewidth 3.0 linecolor 3
> 
> set output
> --- END #1
> 
> --- BEGIN #2
> set term postscript eps enhanced color solid 14
> set output 'key-demo2.eps'
> 
> # try to mimic the positioning of
> #   set key top left Left reverse samplen 2.5 spacing 1.333
> set key at graph 0.45, graph 0.975 Left reverse samplen 2.5 spacing 1.333
> 
> set xrange [0:10]
> set yrange [-1:1]
> 
> plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
>      with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
>      (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
>      with lines linetype 1 linewidth 3.0 linecolor 3
> 
> set output
> --- END #2
> 
> These produce approximately the same output... but I had to find the
> numbers 0.45 and 0.975 in the second script by trial and error.  Moreover,
> the 0.45 must be changed (found by a new round of trial-and-error) if
> I change label font, size, text length.
> 
> You can see this if you try deleting the text "via Fourier series" from
> the label string.  The automatically-placed label is still in the same
> place, but to get that place manually requires changing that 0.45 to
> something more like 0.20 (again determined by trial and error).
> 
> What I (and I think also Philipp K. Janert) would like is a way to find
> those numbers 0.45 and 0.975 without trial and error, preferably in a
> way which doesn't require redoing if I change the label font, size, or
> text length.

I understand what you want, but I don't see how to get there from here.
Even if the program printed out or saved to GPVAL_* the full bounding box of
the key, you couldn't use that to force the same key layout in another plot.
There is just no command or underlying code currently that would do that.

I can see adding a "tweak" command that is marginally easier than finding
magic numbers like 0.45 and 0.975.  But you'd still have to do a trial
plot for each change in font, output device, key title, etc. The "tweak"
would essentially say "ok - do the same thing but offset it by [x,y]
before actually drawing it".

There is a history of requests for more flexibility in key layout,
but no one has volunteered to rewrite or replace the existing code.
I don't mind adding some "tweak" variant, but I'm not going to tackle
anything major in this area myself.

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On 06/19/14 08:39, sfeam wrote:
>
> On Wednesday, 18 June 2014 04:10:12 PM Jonathan Thornburg wrote:
>> Philipp K. Janert wrote:
>>> 3) Key position and offset
>>> A very similar situation arises with the positioning
>>> of the key. Frequently, I am happy with the automatic
>>> positioning, but would like to adjust it slightly.
>>>
>>> I can see two solutions for that: one is that
>>> 	show key
>>> would display the actual position of the margin (so
>>> that this position, when given to "set key at ..."
>>> would reproduce the previous plot),
>>
>> Ethan A Merritt <sf...@us...> replied:
>> : See above.  These values can be retrieved from the GPVAL
>> : variables.
>>
>>> What variables hold the key position? When I
>>> do "show variables all", nothing seems appropriate.
>>
>> : I meant that you can position the key box relative to the plot
>> : border by using, e.g.
>> :
>> :   set key top right at graph 0.98, graph 0.98
>>
>> I've had the same problem as Philipp.  It usually strikes when I'm
>> using the postscript terminal, where gnuplot doesn't know the actual
>> width of the plot key.  I end up doing a fair bit of trial and error
>> to determine either a "width" adjustment to, or an absolute position for,
>> the plot key.
>>
>> An example might make this clearer:  Consider the following two gnuplot
>> scripts (which differ only in their "set key" lines & the names of their
>> output files):
>>
>> --- BEGIN #1
>> set term postscript eps enhanced color solid 14
>> set output 'key-demo.eps'
>>
>> set key top left Left reverse samplen 2.5 spacing 1.333
>>
>> set xrange [0:10]
>> set yrange [-1:1]
>>
>> plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
>>       with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
>>       (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
>>       with lines linetype 1 linewidth 3.0 linecolor 3
>>
>> set output
>> --- END #1
>>
>> --- BEGIN #2
>> set term postscript eps enhanced color solid 14
>> set output 'key-demo2.eps'
>>
>> # try to mimic the positioning of
>> #   set key top left Left reverse samplen 2.5 spacing 1.333
>> set key at graph 0.45, graph 0.975 Left reverse samplen 2.5 spacing 1.333
>>
>> set xrange [0:10]
>> set yrange [-1:1]
>>
>> plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
>>       with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
>>       (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
>>       with lines linetype 1 linewidth 3.0 linecolor 3
>>
>> set output
>> --- END #2
>>
>> These produce approximately the same output... but I had to find the
>> numbers 0.45 and 0.975 in the second script by trial and error.  Moreover,
>> the 0.45 must be changed (found by a new round of trial-and-error) if
>> I change label font, size, text length.
>>
>> You can see this if you try deleting the text "via Fourier series" from
>> the label string.  The automatically-placed label is still in the same
>> place, but to get that place manually requires changing that 0.45 to
>> something more like 0.20 (again determined by trial and error).
>>
>> What I (and I think also Philipp K. Janert) would like is a way to find
>> those numbers 0.45 and 0.975 without trial and error, preferably in a
>> way which doesn't require redoing if I change the label font, size, or
>> text length.
>
> I understand what you want, but I don't see how to get there from here.
> Even if the program printed out or saved to GPVAL_* the full bounding box of
> the key, you couldn't use that to force the same key layout in another plot.
> There is just no command or underlying code currently that would do that.
>
> I can see adding a "tweak" command that is marginally easier than finding
> magic numbers like 0.45 and 0.975.  But you'd still have to do a trial
> plot for each change in font, output device, key title, etc. The "tweak"
> would essentially say "ok - do the same thing but offset it by [x,y]
> before actually drawing it".
>
> There is a history of requests for more flexibility in key layout,
> but no one has volunteered to rewrite or replace the existing code.
> I don't mind adding some "tweak" variant, but I'm not going to tackle
> anything major in this area myself.
>
> 	Ethan
>

Correct me if I'm wrong but this is not just a key text problem. It 
affects all text elements, labels etc.

If something can be done about this, it may help at least mapping out a 
plan of how it could be approached and what needs doing. Even if no one 
has time to start now.

That was my intent with the "Improving text positioning" post.

Peter.

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 15:40:11 Philipp K. Janert wrote:
> On Wed, 18 Jun 2014 15:31:46 -0700
> Ethan A Merritt <sf...@us...> wrote:
> 
> > On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> > 
> > > > > 3) Key position and offset
> > > > > A very similar situation arises with the positioning
> > > > > of the key. Frequently, I am happy with the automatic
> > > > > positioning, but would like to adjust it slightly.
> > > > > 
> > > > > I can see two solutions for that: one is that 
> > > > > 	show key
> > > > > would display the actual position of the margin (so
> > > > > that this position, when given to "set key at ..."
> > > > > would reproduce the previous plot), 
> > > > 
> > > > See above.  These values can be retrieved from the GPVAL
> > > > variables.
> > > 
> > > What variables hold the key position? When I
> > > do "show variables all", nothing seems appropriate.
> > 
> > I meant that you can position the key box relative to the plot
> > border by using, e.g.
> > 
> >   set key top right at graph 0.98, graph 0.98
> 
> But that's not what I mean! I know that I can place
> the key arbitrarily - IFF I know, in absolute terms,
> where I want it!
> 
> My use case is this: I want to use the automatically 
> chosen position as starting point, and then modify it.
> This could be done through an "offset" directive in
> "set key", but it could also be done if I could read
> out the currently chosen key position from some 
> automatically set GPVAL variable. But none of the
> GPVAL vars seems to refer to the current key position.
> 
> Or am I missing something?

I think you are correct that it could only be done by adding a
new parameter equivalent to "offset".   The default positioning
uses an empirical try/oops/try-again approach that is basically
impossible to document usefully.   Note that the empirical positioning
can easily come out differently on different terminals, so even if
we were to add a tweak parameter you'd have to tweak all over
again if you changed the output device.

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wed, 18 Jun 2014 15:53:01 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 18 June, 2014 15:40:11 Philipp K. Janert wrote:
> > On Wed, 18 Jun 2014 15:31:46 -0700
> > Ethan A Merritt <sf...@us...> wrote:
> > 
> > > On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> > > 
> > > > > > 3) Key position and offset
> > > > > > A very similar situation arises with the positioning
> > > > > > of the key. Frequently, I am happy with the automatic
> > > > > > positioning, but would like to adjust it slightly.
> > > > > > 
> > > > > > I can see two solutions for that: one is that 
> > > > > > 	show key
> > > > > > would display the actual position of the margin (so
> > > > > > that this position, when given to "set key at ..."
> > > > > > would reproduce the previous plot), 
> > > > > 
> > > > > See above.  These values can be retrieved from the GPVAL
> > > > > variables.
> > > > 
> > > > What variables hold the key position? When I
> > > > do "show variables all", nothing seems appropriate.
> > > 
> > > I meant that you can position the key box relative to the plot
> > > border by using, e.g.
> > > 
> > >   set key top right at graph 0.98, graph 0.98
> > 
> > But that's not what I mean! I know that I can place
> > the key arbitrarily - IFF I know, in absolute terms,
> > where I want it!
> > 
> > My use case is this: I want to use the automatically 
> > chosen position as starting point, and then modify it.
> > This could be done through an "offset" directive in
> > "set key", but it could also be done if I could read
> > out the currently chosen key position from some 
> > automatically set GPVAL variable. But none of the
> > GPVAL vars seems to refer to the current key position.
> > 
> > Or am I missing something?
> 
> I think you are correct that it could only be done by adding a
> new parameter equivalent to "offset".   The default positioning
> uses an empirical try/oops/try-again approach that is basically
> impossible to document usefully.   Note that the empirical positioning
> can easily come out differently on different terminals, so even if
> we were to add a tweak parameter you'd have to tweak all over
> again if you changed the output device.

Yes, I understand that.

Would it be possible to add two GPVAL vars to hold
the actual (screen?) positions of the x and y coords
of the key?

> 
> 	Ethan

Improving text positioning

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

from "Re: Suggestions for 5.0: Margin (and Key)"

On 06/19/14 00:53, Ethan A Merritt wrote:
> I think you are correct that it could only be done by adding a
> new parameter equivalent to "offset".   The default positioning
> uses an empirical try/oops/try-again approach that is basically
> impossible to document usefully.   Note that the empirical positioning
> can easily come out differently on different terminals, so even if
> we were to add a tweak parameter you'd have to tweak all over
> again if you changed the output device.
>
> 	Ethan


This is the perennial problem of text size and placement coming up again 
and I think it is one of the major flaws in this otherwise excellent 
software.

I know this fundamentally comes from the way gnuplot architecture was 
designed with a plotting core and independent rendering "terminals"

Terminal communication is a one way process and there is currently no 
way for the text rendering facilities available to each terminal to be 
know by the plotting core in order to correctly place text elements. 
This forces some rather crude guessing and often excessive padding to 
avoid text over running axes etc.

This is clearly sub-optimal.

Now I know there are a lot of different contexts to be handled, like a 
postscript file does not even know the  available fonts until it is 
rendered on a particular machine. However, some terminals could do this 
a lot better and it seems everything is being dragged down to a lowest 
common denominator in the present situation.

Here are some suggestions of possible ways to improve things.

  Add some kind of two way communication to terminals like png so that 
precise text extent can be known. Prior to plotting, the plotting core 
sends an extent enquiry with a text sample and the terminal returns text 
extent values that the plotting core can use to precisely place text 
elements.  Then by the time it sends the plot to be rendered it will be 
optimally placed.

For terminals that are too dumb to do this or that themselves do not 
render immediately, so do not have the font metrics available to provide 
a text extent, the fall-back would be the same as it currently is.

Most of the live terminals x11, wxt, qt should be able to provide text 
extent data and that would at least mean working live would give nice 
clean text placements without all the large gaps that are currently 
produced, especially with longer text elements.

A switch could be provided to force the fall-back case for instances 
where a live terminal is being used to prototype output for PS or whatever.


I may be missing something, but I don't see why many of the most common 
and sophisticated terminals could not be made to handle this a lot more 
accurately than is presently the case.

Regards, Peter.

Re: Suggestions for 5.0: Margin (and Key)

[Jonathan T. <jt...@as...>]

Philipp K. Janert wrote:
> 3) Key position and offset
> A very similar situation arises with the positioning
> of the key. Frequently, I am happy with the automatic
> positioning, but would like to adjust it slightly.
> 
> I can see two solutions for that: one is that 
> 	show key
> would display the actual position of the margin (so
> that this position, when given to "set key at ..."
> would reproduce the previous plot), 

Ethan A Merritt <sf...@us...> replied:
: See above.  These values can be retrieved from the GPVAL
: variables.

> What variables hold the key position? When I
> do "show variables all", nothing seems appropriate.

: I meant that you can position the key box relative to the plot
: border by using, e.g.
: 
:   set key top right at graph 0.98, graph 0.98

I've had the same problem as Philipp.  It usually strikes when I'm
using the postscript terminal, where gnuplot doesn't know the actual
width of the plot key.  I end up doing a fair bit of trial and error
to determine either a "width" adjustment to, or an absolute position for,
the plot key.

An example might make this clearer:  Consider the following two gnuplot
scripts (which differ only in their "set key" lines & the names of their
output files):

--- BEGIN #1
set term postscript eps enhanced color solid 14
set output 'key-demo.eps'

set key top left Left reverse samplen 2.5 spacing 1.333

set xrange [0:10]
set yrange [-1:1]

plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
     with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
     (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
     with lines linetype 1 linewidth 3.0 linecolor 3

set output
--- END #1

--- BEGIN #2
set term postscript eps enhanced color solid 14
set output 'key-demo2.eps'

# try to mimic the positioning of
#   set key top left Left reverse samplen 2.5 spacing 1.333
set key at graph 0.45, graph 0.975 Left reverse samplen 2.5 spacing 1.333

set xrange [0:10]
set yrange [-1:1]

plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
     with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
     (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
     with lines linetype 1 linewidth 3.0 linecolor 3

set output
--- END #2

These produce approximately the same output... but I had to find the
numbers 0.45 and 0.975 in the second script by trial and error.  Moreover,
the 0.45 must be changed (found by a new round of trial-and-error) if
I change label font, size, text length.

You can see this if you try deleting the text "via Fourier series" from
the label string.  The automatically-placed label is still in the same
place, but to get that place manually requires changing that 0.45 to
something more like 0.20 (again determined by trial and error).

What I (and I think also Philipp K. Janert) would like is a way to find
those numbers 0.45 and 0.975 without trial and error, preferably in a
way which doesn't require redoing if I change the label font, size, or
text length.

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   currently on the west coast of Canada
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Re: Suggestions for 5.0: Margin (and Key)

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

On 06/19/14 01:10, Jonathan Thornburg wrote:
>
> Philipp K. Janert wrote:
>> 3) Key position and offset
>> A very similar situation arises with the positioning
>> of the key. Frequently, I am happy with the automatic
>> positioning, but would like to adjust it slightly.
>>
>> I can see two solutions for that: one is that
>> 	show key
>> would display the actual position of the margin (so
>> that this position, when given to "set key at ..."
>> would reproduce the previous plot),
>
> Ethan A Merritt <sf...@us...> replied:
> : See above.  These values can be retrieved from the GPVAL
> : variables.
>
>> What variables hold the key position? When I
>> do "show variables all", nothing seems appropriate.
>
> : I meant that you can position the key box relative to the plot
> : border by using, e.g.
> :
> :   set key top right at graph 0.98, graph 0.98
>
> I've had the same problem as Philipp.  It usually strikes when I'm
> using the postscript terminal, where gnuplot doesn't know the actual
> width of the plot key.  I end up doing a fair bit of trial and error
> to determine either a "width" adjustment to, or an absolute position for,
> the plot key.
>
> An example might make this clearer:  Consider the following two gnuplot
> scripts (which differ only in their "set key" lines & the names of their
> output files):
>
> --- BEGIN #1
> set term postscript eps enhanced color solid 14
> set output 'key-demo.eps'
>
> set key top left Left reverse samplen 2.5 spacing 1.333
>
> set xrange [0:10]
> set yrange [-1:1]
>
> plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
>       with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
>       (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
>       with lines linetype 1 linewidth 3.0 linecolor 3
>
> set output
> --- END #1
>
> --- BEGIN #2
> set term postscript eps enhanced color solid 14
> set output 'key-demo2.eps'
>
> # try to mimic the positioning of
> #   set key top left Left reverse samplen 2.5 spacing 1.333
> set key at graph 0.45, graph 0.975 Left reverse samplen 2.5 spacing 1.333
>
> set xrange [0:10]
> set yrange [-1:1]
>
> plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
>       with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
>       (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
>       with lines linetype 1 linewidth 3.0 linecolor 3
>
> set output
> --- END #2
>
> These produce approximately the same output... but I had to find the
> numbers 0.45 and 0.975 in the second script by trial and error.  Moreover,
> the 0.45 must be changed (found by a new round of trial-and-error) if
> I change label font, size, text length.
>
> You can see this if you try deleting the text "via Fourier series" from
> the label string.  The automatically-placed label is still in the same
> place, but to get that place manually requires changing that 0.45 to
> something more like 0.20 (again determined by trial and error).
>
> What I (and I think also Philipp K. Janert) would like is a way to find
> those numbers 0.45 and 0.975 without trial and error, preferably in a
> way which doesn't require redoing if I change the label font, size, or
> text length.
>
> ciao,
>

Thanks for the example.

I've started a new thread where I suggest how this text placement 
problem could be addressed, since I think the whole discussion about 
margins is a work around for this core issue of text placement and extent.

Margins is not without merit as a discussion in the context of current 
gnuplot and may have wider application, so I've split my comments as a 
new thread discuss the underlying problem separately from the work around.

As I understand PS ( which I don't use much ) it relies on the fonts of 
the host machine at the time it is printed, unless huge font information 
is embedded in the PS file.

I suspect this will mean that this kind of careful hand tuning may come 
unstuck when the PS plot is printed elsewhere than on the machine where 
the manual optimisation was done.

If you are printing locally it should work fine.


Peter.

Re: Suggestions for 5.0: Margin (and Key)

[sfeam <sf...@us...>]

On Thursday, 19 June 2014 09:35:55 AM pl...@pi... wrote:

> As I understand PS ( which I don't use much ) it relies on the fonts of 
> the host machine at the time it is printed, unless huge font information 
> is embedded in the PS file.
> 
> I suspect this will mean that this kind of careful hand tuning may come 
> unstuck when the PS plot is printed elsewhere than on the machine where 
> the manual optimisation was done.
> 
> If you are printing locally it should work fine.

It's worse than you think.
The font choice in PostScript is made by the printer, not the machine
from which the print command originated.  So the problem can in principle
arise even when you are printing locally.  

In practice this is usually only an issue for non-standard fonts, and you
do still have the option of embedding the font in the document.

	Ethan