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.