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


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

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

From Janis Papanagnou <janis_papanagnou@hotmail.com>
Newsgroups comp.graphics.apps.gnuplot
Subject Re: Labelling bug with xtics offset if y2-axis is activated
Date 2015-08-18 14:17 +0200
Organization Aioe.org NNTP Server
Message-ID <mqv7pk$fo4$1@speranza.aioe.org> (permalink)
References <mqtfa8$v0l$1@speranza.aioe.org> <mqtv6i$22c$1@solani.org> <mquerb$3l1$1@dont-email.me>

Show all headers | View raw


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.

(Mind; the label shifting in case of dates on the axis had already been
a workaround. - Is it sensible if you label, say, days at the start of
the day (instead of the mid of the day), or label years at 1st January
(instead of the mid of the year)? - This just as a note aside. - The
gnuplot concept is very primitive here; it assumes "Monday" to have to
mean "Monday, 00:00", and "2015" to mean "2015-01-01". For date ranges
labels this is usually - and if you think about it also conceptually;
compare date data points vs. date ranges - inappropriate. YMMV.)

> 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.

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 | NextPrevious 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