Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.graphics.apps.gnuplot > #3046
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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