Menu
▾
▴
gnuplot-beta
|
From: Mike S. <mw...@us...> - 2007-01-28 21:00:56
|
I was trying to plot some data with labels and points from a data file and =
got=20
the following error when the "offset" option was used. It seems that the=20
comma in the offset specification confuses the command line parser. A work=
=20
around is to make sure the "with labels" is the last thing plotted. I thin=
k=20
a note should be added to the 4.2 documentation about this limitation.
plot 'mike3.dat' with labels left offset 3,3 , 'mike4.dat' with points
duplicated or contradicting arguments in plot options
=46rom the documentation for "with labels"
> The font, color, rotation angle and other properties of the printed text =
may
> be specified as additional command options .=20
So I started playing around with the text color. =20
plot 'mike3.dat' w labels left tc rgb "blue"
This works for RC4 but not for the CVS HEAD (4.3). I have not investigated=
=20
why "tc rgb 'color'" does not work for 4.3. It always comes up black.=20
However, using "tc lt #" does work as expected.
I have also thought that the addition of a label style, analogous to=20
linestyle, would be useful.
Mike Sutton
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-01-28 21:43:13
|
On Sunday 28 January 2007 12:58, Mike Sutton wrote: > The comma in the offset specification confuses the command line parser. > plot 'mike3.dat' with labels left offset 3,3 , 'mike4.dat' with points > duplicated or contradicting arguments in plot options Yes, I had totally forgotten about that. Thanks for the reminder. It is a known problem, but is probably fixable. > A work around is to make sure the "with labels" is the last thing plotted. Other work-arounds: - Give a dummy z coordinate in the offset plot 'mike3' with labels left offset 3,3,0, 'mike4' with points - put an attribute keyword after the offset plot 'mike3' with labels offset 3,3 left, 'mike4' with points - even if it's a useless attribute plot 'mike3' with labels offset 3,3 nopoint, 'mike4' with points > I think a note should be added to the 4.2 documentation about this limitation. Yes, if no trivial fix is found. The trick will be to put the note in a place that users will actually find. > So I started playing around with the text color. > plot 'mike3.dat' w labels left tc rgb "blue" > > This works for RC4 but not for the CVS HEAD (4.3). I have not investigated > why "tc rgb 'color'" does not work for 4.3. It always comes up black. Huh. You are right. That's a strange one. I have absolutely no idea what has gone wrong. > I have also thought that the addition of a label style, analogous to > linestyle, would be useful. I have a slightly different approach already on my TODO list. Rather than using linestyle as a model, I was thinking that there should be the equivalent of set style histogram set style fill set style object rectangle Each of these defines a set of default properties for all instances of the respective plot elements. In the case of labels, my idea was that if a specific label command does not set a font, say, then its font field is set to DEFAULT and inherits the current value in the generic label style. Thus if you were to set 100 labels in advance, perhaps plotting to judge visual effect, you could change all of them at once to use a smaller font by saying set style label font "Times,9" I take it your idea is similar, except that there would be multiple predefined label styles rather than a single default style. Right? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2007-01-28 22:32:14
|
Ethan A Merritt wrote: > On Sunday 28 January 2007 12:58, Mike Sutton wrote: > >>The comma in the offset specification confuses the command line parser. >> plot 'mike3.dat' with labels left offset 3,3 , 'mike4.dat' with points >> duplicated or contradicting arguments in plot options > > > Yes, I had totally forgotten about that. Thanks for the reminder. > It is a known problem, but is probably fixable. > > >>A work around is to make sure the "with labels" is the last thing plotted. > > > Other work-arounds: > - Give a dummy z coordinate in the offset > plot 'mike3' with labels left offset 3,3,0, 'mike4' with points > - put an attribute keyword after the offset > plot 'mike3' with labels offset 3,3 left, 'mike4' with points > - even if it's a useless attribute > plot 'mike3' with labels offset 3,3 nopoint, 'mike4' with points > I wasn't aware this issue came up elsewhere. I think this is the same problem as we skirted with a change in syntax to something else that used commas in the binary format string. That is, we changed a comma to a colon, but in that case the comma wasn't used as a delimiter for something like coordinates. Not sure this is fixable. The problem is that one has to sort of advance the parse pointer a little too far and move on before making a final decision about how to treat the numbers. For example, note the slight difference between these two lines, both of them valid: plot 'mike3' with labels left offset 3,3,0, 'mike4' with points plot 'mike3' with labels left offset 3,3,0 with points Yes, it is clear that their is a second plot and it is zero as one looks at it, but that doesn't become clear until the "with" is interpreted which from a programming perspective is too far down the line. The problem is that an "isolated" or "stand alone" comma has multiple meanings. The only ways around this, it seems to me, is to change the syntax of end of line (difficult to deprecate something like that, but could allow new syntax that hasn't ambiguity) or restrict the use of comma somewhat (again, difficult to change at this point). Unfortunately semicolon and backslash are already used. There is a straight line "|" plot 'mike3' with labels left offset 3,3 | 'mike4' with points also, ~ < > - & (actually "and" would be a not-so-illogical choice) and then possible double character use .. ;; \\. The other approach would be to restrict coordinates to include parentheses, e.g., plot 'mike3' with labels left offset (3,3), 'mike4' with points Dan |
