Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-06 12:11:02
|
Daniel J Sebald wrote:
> gnuplot> set key right outside top right
> ^
> warning: Multiple horizontal position settings
>
> where the second occurrence of the horizontal position overrides the
> first occurrence? This would be setting a precedent perhaps for
> multiple specs for all commands?
Actually I think we already have some precedence for repeated options.
See set.c:set_label(), and all the TBOOLEAN flags like set_position are
handled: repetition of "strong" options is treated as an error:
gnuplot> set label 'text' at 1,2 at 3,4
^
extraneous or contradicting arguments in label options
The difference in your current "set key" is that some options' effects
are "weak", i.e. they only set a default for some other choice, which is
expressly allowed to be overwritten by an explicit specification.
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-06 16:39:12
|
Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
>
>> gnuplot> set key right outside top right
>> ^
>> warning: Multiple horizontal position settings
>>
>> where the second occurrence of the horizontal position overrides the
>> first occurrence? This would be setting a precedent perhaps for
>> multiple specs for all commands?
>
>
> Actually I think we already have some precedence for repeated options.
> See set.c:set_label(), and all the TBOOLEAN flags like set_position are
> handled: repetition of "strong" options is treated as an error:
>
> gnuplot> set label 'text' at 1,2 at 3,4
> ^
> extraneous or contradicting arguments in label options
>
> The difference in your current "set key" is that some options' effects
> are "weak", i.e. they only set a default for some other choice, which is
> expressly allowed to be overwritten by an explicit specification.
Yes, but there are a large number where an obvious conflict is present. How about creating a special error for this? Something that might be called as:
int_conflict_error(c_token, "label");
int_conflict_error(c_token, "key");
Dan
PS: I forgot the revamped key documentation:
[...]
Syntax:
set key {on|off} {default}
{{inside | outside} | {lmargin | rmargin | tmargin | bmargin}
| {at <position>}}
{left | right | center} {top | bottom | center}
{vertical | horizontal} {Left | Right}
{{no}reverse} {{no}invert}
{samplen <sample_length>} {spacing <vertical_spacing>}
{width <width_increment>}
{height <height_increment>}
{{no}autotitle {columnheader}}
{title "<text>"} {{no}enhanced}
{{no}box { {linestyle | ls <line_style>}
| {linetype | lt <line_type>}
{linewidth | lw <line_width>}}}
unset key
show key
Plots may be drawn with no visible key by requesting `set key off` or
`unset key`.
Elements within the key are stacked according to `vertical` or `horizontal`.
In the case of `vertical`, the key occupies as few columns as possible. That
is, elements are aligned in a column until running out of vertical space at
which point a new column is started. In the case of `horizontal`, the key
occupies as few rows as possible.
By default the key is placed in the upper right inside corner of the graph.
The keywords `left`, `right`, `top`, `bottom`, `center`, `inside`, `outside`,
`lmargin`, `rmargin`, `tmargin`, `bmargin` (, `above`, `over`, `below` and
`under`) may be used to automatically place the key in other positions of the
graph. Also an `at <position>` may be given to indicate precisely where the
plot should be placed. In this case, the keywords `left`, `right`, `center`,
`bottom` and `center` serve an analogous purpose for alignment.
To understand positioning, the best concept is to think of a region, i.e.,
inside/outside, or one of the margins. Along with the region, keywords
`left/center/right` (l/c/r) and `top/center/bottom` (t/c/b) control where
within the particular region the key should be placed.
When in `inside` mode, the keywords `left` (l), `right` (r), `top` (t),
`bottom` (b), and `center` (c) push the key out toward the plot boundary as
illustrated:
t/l t/c t/r
c/l c c/r
b/l b/c b/r
When in `outside` mode, automatic placement is similar to the above
illustration, but with respect to the view, rather than the graph boundary.
That is, a border is moved inward to make room for the key outside of
the plotting area, although this may interfere with other labels and may
cause an error on some devices. The particular plot border that is moved
depends upon the position described above and the stacking direction. For
options centered in one of the dimensions, there is no ambiguity about which
border to move. For the corners, when the stack direction is `vertical`, the
left or right border is moved inward appropriately. When the stack direction
is `horizontal`, the top or bottom border is moved inward appropriately.
The margin syntax allows automatic placement of key regardless of stack
direction. When one of the margins `lmargin` (lm), `rmargin` (rm),
`tmargin` (tm), and `bmargin` (bm) is combined with a single, non-conflicting
direction keyword, the following illustrated positions may contain the key:
l/tm c/tm r/tm
t/lm t/rm
c/lm c/rm
b/lm b/rm
l/bm c/bm r/bm
Keywords `above` and `over` are synonymous with `tmargin`. For version
compatibility, `above` or `over` without an additional l/c/r or stack direction
keyword uses `center` and `horizontal`. Keywords `below` and `under` are
synonymous with `bmargin`. For compatibility, `below` or `under` without an
additional l/c/r or stack direction keyword uses `center` and `horizontal`. A
further compatibility issue is that `outside` appearing without an additional
t/b/c or stack direction keyword uses `top`, `right` and `vertical` (i.e., the
same as t/rm above).
The <position> can be a simple x,y,z as in previous versions, but these can
be preceded by one of five keywords (`first`, `second`, `graph`, `screen`,
`character`) which selects the coordinate system in which the position of
the first sample line is specified. See `coordinates` for more details.
The effect of `left`, `right`, `top`, `bottom`, and `center` when <position>
is given is to align the key as though it were text positioned using the
label command, i.e., `left` means left align with key to the right of
<position>, etc.
[...]
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-07 07:16:33
|
OK, I'm done with the key layout, unless there is something people want added. I suggest adding this patch soon. Syntax is good, I think. The code is cleaner than the current. We can touch up and loose ends rather easily after the fact.
The 3D key box may not be as robust as 2D (still works the same for the demos), but I say let's cross that bridge when we come to it. (I'd propose unifying 2D/3D as a better alternative than attempting a complete revamping of 3D key.)
The 'all.dem' will show three or four plots as slightly different. For example, in the current CVS version, simple.dem has:
set key outside below
plot [-5*pi:5*pi] [-5:5] real(tan(x)/atan(x)), 1/x
pause -1 "Hit return to continue"
set key left box
set autoscale
set samples 800
plot [-30:20] sin(x*20)*atan(x)
pause -1 "Hit return to continue"
Currently, that "set key left" seems to do nothing at all, as it may not make sense in the current cvs. (The key stays "below" from the previous plot.) The new setup will position the key below and to the left.
Something that is strange in current CVS is prob.dem:
set key bottom outside
plot [0:2] [0:1.1] a = 2.0, n = 1, sine(x) title "a = 2.0, n = 1", \
a = 2.0, n = 3, sine(x) title "a = 2.0, n = 3"
pause -1 "Hit return to continue"
set title "sine CDF"
set key top left
plot [0:2] [0:1.1] a = 2.0, n = 1, csine(x) title "a = 2.0, n = 1", \
a = 2.0, n = 3, csine(x) title "a = 2.0, n = 3"
puts the key of the second plot at the *inside* of the plot. Now that seems like a silly behavior to be backward compatible to. (For the synonyms "above", "below", "under", "over" assuming a position is fine, but not the more abstract "top left".) I'd suggest changing prob.dem to "set key top left inside" if the plots in that demo are to remain as is.
I looked at the set_label() code Hans pointed out. That is a creative way of implementing conflicting keywords (and I notice that nothing is changed until the whole line syntax is verified). However, I'm going to leave the warnings I implemented as is; for two reasons. One, what I've done is slightly more flexible if detailed warnings are desired. Two, the warnings (as opposed to error) will not cause the "outside below" of the above example to fail during the demos. We then have examples of doing this a variety of ways and can discuss pros/cons on the list.
So, the July 7 patch should do nicely.
Dan
|
