Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #3050

Re: Labelling bug with xtics offset if y2-axis is activated

Show key headers only | View raw

Janis Papanagnou wrote:

> On 18.08.2015 07:13, sfeam wrote:
>> Karl-Friedrich Ratzsch wrote:
>> 
>>> Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:
>>>
>>>> As you can see, in the second case the X-axis annotation is flawed,
>>>> it contains a spurious "Mon" tag off the drawing area.
>>>>
>>>> Is that misbehaviour still the case with the current gnuplot
>>>> version, so that a bug-report shall be issued?
>>>
>>>
>>> As expected, yes. I'm not sure this qualifies as a bug, but one
>>> could argue that a ticslabel that gets shifted outside of the axis
>>> range should not get printed any more.
> 
> I have a strong opinion about that; and the reason you gave is exactly
> what I think. (More rationales below.)
> 
>> 
>> I do not consider it a bug.
>> If the user has a reason to shift all the labels to the left or
>> right, why should the program suddenly not draw one?
> 
> Because there should be clipping functionality active; as other
> software sensibly does in similar cases. Moreover; if you compare the
> two posted cases you see that in the first output, despite the shift,
> the label is *not* printed. In the first case it's outside the drawing
> area and not printed and in the second case it's outside the drawing
> area and printed; it should at least be handled consistently. But in
> both cases there are also no data points associated; data is
> restricted to the drawing area.
>[snip]
> 
>> If it were my plot in
>> that case, I'd be very annoyed if the label were suddenly not plotted
>> at all just because I gave an offset.
> 
> The label should only be clipped if it's outside the drawing area; in
> that case you also have no data points or curves outside the drawing
> area which would make a label meaningful.

The rationale for clipping is this:

(1) If an element is part of the data being plotted, it is clipped to the
interior of the graph box (graph coordinate range [0:1]).
This includes labels generated by "plot $foo with labels".

(2) If an element is not part of the graph, i.e. labels generated by
"set label", it is clipped to the canvas (screen coordinate range [0:1].

Tic and axis labels are outside the graph box, and therefore fall in
category 2.   On the other hand, if you generate tic labels from the
data, as in "plot $foo using 1:2:xticlabel(3)" then they would indeed
be clipped to the plot since the data points that generate them are
clipped by (1).

	Ethan


> Given the "featuritis" way of gnuplot design (as some previous comment
> suggested), a new feature "set really-clip-to-drawing-area" (instead
> of a correcture) might be more in the spirit of gnuplot users? - No,
> I'm not, or only partly serious and partly sarcastic. The serious part
> is that, whatever the default behaviour (sensible or not) would be,
> you would have explicit control by a boolean flag about the actual
> behaviour, whether the drawing area margins are respected or not. From
> a user's perspective I'd consider that at least more user friendly
> than any hard coded tics solution, or any solution that's only
> applicable if the data range is known in advance.
> 
>> 
>> 
>> By the way.  As to why no bug report has previously been filed
>> for "set [xy]tics offset <xdel>", my guess is that people accomplish
>> essentially the same thing by changing the format instead.
>> E.g.
>>      set xtics format "   %.2g" left
> 
> The hard-coded spaces look like the format would be depending on the
> actual number of tics; right? But this would qualify as an unrealiable
> hack, since this precondition is not fulfilled; it's depending on the
> actual data set. (YMMV, of course.)
> 
> So one opinion here is "maybe it's a bug", the other one "it's no
> bug".
> 
> Anyway, beside getting feedback for the current version - which would
> give me a reason to update the software -, one reason whyI posted was
> get opinions. The other reason was the hint (elsewhere) to file bug
> reports. Given that this - IMO obvious - misbehaviour is still
> disputed and argued about I'll abstain from further actions.
> 
> Thanks, Karl and Ethan, for your feedback.
> 
> Janis
> 
>> [...]

Back to comp.graphics.apps.gnuplot | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Labelling bug with xtics offset if y2-axis is activated Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-17 22:14 +0200
  Re: Labelling bug with xtics offset if y2-axis is activated Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-18 02:45 +0200
    Re: Labelling bug with xtics offset if y2-axis is activated sfeam <sfeam@users.sourceforge.net> - 2015-08-17 22:13 -0700
      Re: Labelling bug with xtics offset if y2-axis is activated Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-18 14:17 +0200
        Re: Labelling bug with xtics offset if y2-axis is activated Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-18 15:22 +0200
        Re: Labelling bug with xtics offset if y2-axis is activated sfeam <sfeam@users.sourceforge.net> - 2015-08-18 21:37 -0700
    Re: Labelling bug with xtics offset if y2-axis is activated Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-18 14:27 +0200
      Re: Labelling bug with xtics offset if y2-axis is activated Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-18 14:57 +0200

csiph-web