Menu
▾
▴
gnuplot-beta
|
From: Achim G. <Str...@ne...> - 2017-10-11 17:11:36
|
I've been building gnuplot for Cygwin from the stable branch over the weekend in order to get the fix for the log axis regression. I have the grid lines and tics back in my plot, but there is yet another regression: The 5.0 branch will put the major tics on integer exponents of the base. The 5.2 branch will only do that if the first defined tic is located inside the axis range and otherwise uses the lower end of the range to start from. This is interesting and maybe even useful sometimes, but it breaks a lot of plotting scripts, so it shouldn't do this by default I think. To reproduce: --8<---------------cut here---------------start------------->8--- set log x 10 set mxtics 10 set xtics 10 set xrange [pi:1e4*pi] plot sin(x) --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- set log x 10 set mxtics 10 set xtics 3,10 set xrange [pi:1e4*pi] plot sin(x) --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- set log x 10 set mxtics 10 set xtics 4,10 set xrange [pi:1e4*pi] plot sin(x) --8<---------------cut here---------------end--------------->8--- I hope this can still be fixed for 5.2.1 (fingers crossed). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs |
|
From: sfeam <sf...@us...> - 2017-10-12 03:36:09
|
On Wednesday, 11 October 2017 19:11:08 Achim Gratz wrote: > > I've been building gnuplot for Cygwin from the stable branch over the > weekend in order to get the fix for the log axis regression. I have the > grid lines and tics back in my plot, but there is yet another > regression: > The 5.0 branch will put the major tics on integer exponents > of the base. > The 5.2 branch will only do that if the first defined tic > is located inside the axis range and otherwise uses the lower end of the > range to start from. Yup. Good diagnosis. There is a line of code that does exactly that. I agree this is probably not what people expect, so that line can go. > I hope this can still be fixed for 5.2.1 (fingers crossed). I will make that change. No promises that another wrinkle will not appear. Some of the very oldest entries in the project bug tracker were complaints about the handling of log-scale tic placement. The revision of log-scale handling in 5.0 allowed us to close them a mere 25 years later. But even so it's evidently not yet perfect. Ethan > Regards, > Achim. > |
|
From: Achim G. <Str...@ne...> - 2017-10-12 18:04:48
|
sfeam via gnuplot-beta writes: > I will make that change. No promises that another wrinkle will not > appear. Well, once I see it appear in the repo I'll do a new build and run our plotting scripts @work against it. I had to rollback to 5.0.7 pretty quickly so I can't really say if there were no other problems, but nothing else that was glaringly obvious. > Some of the very oldest entries in the project bug tracker > were complaints about the handling of log-scale tic placement. I can imagine. > The revision of log-scale handling in 5.0 allowed us to close them > a mere 25 years later. But even so it's evidently not yet perfect. I just needs to be good enough. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada |
|
From: Achim G. <Str...@ne...> - 2017-10-19 18:06:01
|
Achim Gratz writes: > Well, once I see it appear in the repo I'll do a new build and run our > plotting scripts @work against it. I had to rollback to 5.0.7 pretty > quickly so I can't really say if there were no other problems, but > nothing else that was glaringly obvious. So I finally did that today and there is still one tiny bit of regression left (I could have seen that in my original test cases already, but I didn't look closely enough). In the following example you'll see that the tics are only starting from 10^0=1 instead of from the smallest fractional power of of 10. --8<---------------cut here---------------start------------->8--- set log x 10 set mxtics 10 set xtics 10 set xrange [1e-3*pi:pi] plot sin(x) --8<---------------cut here---------------end--------------->8--- Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables |
|
From: Daniel J S. <dan...@ie...> - 2017-10-19 18:20:30
|
On 10/19/2017 01:05 PM, Achim Gratz wrote: > Achim Gratz writes: >> Well, once I see it appear in the repo I'll do a new build and run our >> plotting scripts @work against it. I had to rollback to 5.0.7 pretty >> quickly so I can't really say if there were no other problems, but >> nothing else that was glaringly obvious. > > So I finally did that today and there is still one tiny bit of > regression left (I could have seen that in my original test cases > already, but I didn't look closely enough). In the following example > you'll see that the tics are only starting from 10^0=1 instead of from > the smallest fractional power of of 10. > > --8<---------------cut here---------------start------------->8--- > set log x 10 > set mxtics 10 > set xtics 10 > set xrange [1e-3*pi:pi] > plot sin(x) > --8<---------------cut here---------------end--------------->8--- Did you mean to write set xtics 0.1 rather than 10? For mxtics the number means frequency <freq> (i.e., how many intervals to break into), while for xtics the number means increment <incr> (i.e., the length of each interval). With xtics increment of 10 there are no visible ticks on the x axis. Dan |
|
From: Achim G. <Str...@ne...> - 2017-10-19 18:26:14
|
> Did you mean to write > > set xtics 0.1 > > rather than 10? No, I really meant to write 10, which until version 5.2 meant that the tics would be spaced a decade (factor of 10) on a logscale axis. > For mxtics the number means frequency <freq> (i.e., > how many intervals to break into), while for xtics the number means > increment <incr> (i.e., the length of each interval). With xtics > increment of 10 there are no visible ticks on the x axis. There are, just not on the complete axis at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables |
|
From: Achim G. <Str...@ne...> - 2017-10-20 19:33:09
|
Achim Gratz writes:
> So I finally did that today and there is still one tiny bit of
> regression left (I could have seen that in my original test cases
> already, but I didn't look closely enough). In the following example
> you'll see that the tics are only starting from 10^0=1 instead of from
> the smallest fractional power of of 10.
I don't really know what I'm doing, but this patch seems to fix this
issue. I don't know if it causes a regression somewhere else.
--8<---------------cut here---------------start------------->8---
--- origsrc/gnuplot-branch-5-2-stable/src/axis.c 2017-10-14 02:00:11.000000000 +0200
+++ src/gnuplot-branch-5-2-stable/src/axis.c 2017-10-20 21:23:34.189778800 +0200
@@ -1151,9 +1151,7 @@ gen_tics(struct axis *this, tic_callback
*/
step = eval_link_function(this->linked_to_primary, step);
end = eval_link_function(this->linked_to_primary, end);
- if (start <= 0)
- start = step;
- else
+ if (start > 0)
start = eval_link_function(this->linked_to_primary, start);
lmin = this->linked_to_primary->min;
lmax = this->linked_to_primary->max;
--8<---------------cut here---------------end--------------->8---
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
|
|
From: Achim G. <Str...@ne...> - 2017-10-25 19:48:12
|
Achim Gratz writes: > I don't really know what I'm doing, but this patch seems to fix this > issue. I don't know if it causes a regression somewhere else. I#ve got a PM from Ethan about my patch, but my answer did not seem to have reached him. One concern was about my patch ignoring the axis range. If I'm reading the code correctly, that was taken care of a few lines earlier in the code when start was getting set to just below the min of the axis. THe other question was about what this is trying to achieve: This is about specifying a log series with undefined start and end, working on an axis which has later been set up to have a defined range whose ends do not coincide with the major tics. Since the axis can start before the first major tic inside its range, you must define the start to be the first correct position just outside the axis min or the minor tics that still lie inside the range are not visible. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada |
|
From: Ethan A M. <sf...@us...> - 2017-10-25 20:18:50
|
On Wednesday, October 25, 2017 12:47:37 PM PDT Achim Gratz wrote: > Achim Gratz writes: > > I don't really know what I'm doing, but this patch seems to fix this > > issue. I don't know if it causes a regression somewhere else. > > I#ve got a PM from Ethan about my patch, but my answer did not seem to > have reached him. I was deferring action because of the freeze on cvs/git commits, but I was planning to include a fix for this in 5.2.1 tarball even it doesn't hit the source repository until the cvs->git conversion completes. > One concern was about my patch ignoring the axis range. If I'm reading > the code correctly, that was taken care of a few lines earlier in the > code when start was getting set to just below the min of the axis. The code is confusing, but it is easy enough to test what happens. What I see is that with your patch "as is" the first x-axis tic mark does not change as I gradually extend the lower end range on x. I added a while loop to push the start point for tic generation back past the lower limit. Note that the tic placement code will simply ignore tics that are out of range, so placing the start point a bit lower than strictly necessary does not hurt. > THe other question was about what this is trying to achieve: This is > about specifying a log series with undefined start and end, working on > an axis which has later been set up to have a defined range whose ends > do not coincide with the major tics. Since the axis can start before > the first major tic inside its range, you must define the start to be > the first correct position just outside the axis min or the minor tics > that still lie inside the range are not visible. Right. I'll send you a copy of the patch and/or a preliminary tarball offline if you like. Ethan > Regards, > Achim. |
|
From: Achim G. <Str...@ne...> - 2017-10-26 06:03:37
|
Ethan A Merritt via gnuplot-beta writes: > On Wednesday, October 25, 2017 12:47:37 PM PDT Achim Gratz wrote: >> Achim Gratz writes: >> > I don't really know what I'm doing, but this patch seems to fix this >> > issue. I don't know if it causes a regression somewhere else. >> >> I#ve got a PM from Ethan about my patch, but my answer did not seem to >> have reached him. > > I was deferring action because of the freeze on cvs/git commits, > but I was planning to include a fix for this in 5.2.1 tarball even it > doesn't hit the source repository until the cvs->git conversion completes. No problem, I just wasn't sure if my mail reached you. >> One concern was about my patch ignoring the axis range. If I'm reading >> the code correctly, that was taken care of a few lines earlier in the >> code when start was getting set to just below the min of the axis. > > The code is confusing, but it is easy enough to test what happens. > What I see is that with your patch "as is" the first x-axis tic mark does > not change as I gradually extend the lower end range on x. > I added a while loop to push the start point for tic generation back > past the lower limit. Note that the tic placement code will simply > ignore tics that are out of range, so placing the start point a bit > lower than strictly necessary does not hurt. As I said, I didn't really know what I'm doing there, but it seemed to fix the problem in my limited testing. >> THe other question was about what this is trying to achieve: This is >> about specifying a log series with undefined start and end, working on >> an axis which has later been set up to have a defined range whose ends >> do not coincide with the major tics. Since the axis can start before >> the first major tic inside its range, you must define the start to be >> the first correct position just outside the axis min or the minor tics >> that still lie inside the range are not visible. > > Right. > I'll send you a copy of the patch and/or a preliminary tarball offline > if you like. I can't test it on production code for about the next two weeks (I might build it before), but having the patch works just fine for me, no need for a tarball. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada |
|
From: Achim G. <Str...@ne...> - 2017-11-06 19:53:03
|
Achim Gratz writes: > I can't test it on production code for about the next two weeks (I might > build it before), but having the patch works just fine for me, no need > for a tarball. I've released 5.2.1 for Cygwin and have tested it today. There are some seemingly harmless (if annoying) warnings about the linked axes not matching up as expected and the symptom in general seems to be that the sign of the two values that are supposedly identical are reversed. I have to get to the bottom of it later. The only other difference to 5.0.7 I've noticed is that the key box in some cases overlaps with some labeling outside the main plot area. Again, I don't know exactly when and why that happens, but I will eventually try to find out. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada |
|
From: Ethan A M. <sf...@us...> - 2017-11-06 20:19:42
|
On Monday, November 6, 2017 11:52:48 AM PST Achim Gratz wrote: > Achim Gratz writes: > > I can't test it on production code for about the next two weeks (I > > might > > build it before), but having the patch works just fine for me, no need > > for a tarball. > > I've released 5.2.1 for Cygwin and have tested it today. There are some > seemingly harmless (if annoying) warnings about the linked axes not > matching up as expected and the symptom in general seems to be that the > sign of the two values that are supposedly identical are reversed. That's unexpected, since the test is now being made against the absolute value of the difference, so sign should not matter. If you can provide a script that shows the problem, I'd like to fix it before packaging up 5.2.2 > I have to get to the bottom of it later. The only other difference to > 5.0.7 I've noticed is that the key box in some cases overlaps with some > labeling outside the main plot area. Again, I don't know exactly when > and why that happens, but I will eventually try to find out. Are these 3D plots? Have a look at the documentation for "set key fixed". Ethan > > Regards, > Achim. |
|
From: Achim G. <Str...@ne...> - 2017-11-06 20:30:46
|
Ethan A Merritt via gnuplot-beta writes: >> I've released 5.2.1 for Cygwin and have tested it today. There are some >> seemingly harmless (if annoying) warnings about the linked axes not >> matching up as expected and the symptom in general seems to be that the >> sign of the two values that are supposedly identical are reversed. > > That's unexpected, since the test is now being made against the > absolute value of the difference, so sign should not matter. > If you can provide a script that shows the problem, I'd like to fix it > before packaging up 5.2.2 Right now it's somewhere in a 1800 pages PDF report, I'll have to isolate the offending plots and get at the gnuplot code for that. For now I only know that those plots I've looked at didn't show any unexpected defects, so the warning seems to be spurious as far as the result goes. >> I have to get to the bottom of it later. The only other difference to >> 5.0.7 I've noticed is that the key box in some cases overlaps with some >> labeling outside the main plot area. Again, I don't know exactly when >> and why that happens, but I will eventually try to find out. > > Are these 3D plots? No, distribution plots, sometimes with reversed and/or logarithmic axes. > Have a look at the documentation for "set key fixed". I'll have to trace the same steps as outlined above, then I can be back with more questions (unless it's already obvious by then). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs |
|
From: Achim G. <Str...@ne...> - 2017-11-07 20:48:59
|
Achim Gratz writes: > Right now it's somewhere in a 1800 pages PDF report, I'll have to > isolate the offending plots and get at the gnuplot code for that. For > now I only know that those plots I've looked at didn't show any > unexpected defects, so the warning seems to be spurious as far as the > result goes. This one _should_ be simple to fix: The warnings get issued when a previous plot used a reverse linear axis that is constrained to negative values and the next plot uses a logarithmic axis. To reproduce: --8<---------------cut here---------------start------------->8--- set xrange [-2*pi:-pi] reverse set xrange [*:*] noreverse set log x --8<---------------cut here---------------end--------------->8--- The error does not happen if the max of the first xrange is positive. It seems that switching on autoscale does not correctly invalidate some of the internal variables set up by the first xrange. The explanation for why this error is not having consequences on my plots is that the correct range for the (now logarithmic) axis will always be set later on. Regards Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada |
|
From: Ethan A M. <sf...@us...> - 2017-11-07 21:42:36
|
On Tuesday, November 7, 2017 12:48:39 PM PST Achim Gratz wrote: > Achim Gratz writes: > > Right now it's somewhere in a 1800 pages PDF report, I'll have to > > isolate the offending plots and get at the gnuplot code for that. For > > now I only know that those plots I've looked at didn't show any > > unexpected defects, so the warning seems to be spurious as far as the > > result goes. > > This one _should_ be simple to fix: The warnings get issued when a > previous plot used a reverse linear axis that is constrained to negative > values and the next plot uses a logarithmic axis. To reproduce: > > --8<---------------cut here---------------start------------->8--- > set xrange [-2*pi:-pi] reverse > set xrange [*:*] noreverse > set log x > --8<---------------cut here---------------end--------------->8--- Hold on a minute. That first line is not a legal command in version 5, or at any rate it is meaningless. The "reverse" keyword only applies to autoscaling. If that command is actually doing something, that's a bug all by itself. ... [thinking] ... On the other hand, that spurious warning is generated even without "reverse/noreverse" involved. I think the actual error is that set xrange [*:*] turns on autoscaling but does not erase the previous min/max. Since they were both negative numbers, "set log" complains. The code has a special check that handles the default axis range setting [-10:10]. Maybe that check should be extended to cover all cases of negative range limits? Not sure. But really I think the problem is that "set auto" and "set range [*:*] don't actually clear the previous limits. Unfortunately I suspect that the "refresh" command relies on that, so the best fix is not immediately clear. Ethan > > The error does not happen if the max of the first xrange is positive. > It seems that switching on autoscale does not correctly invalidate some > of the internal variables set up by the first xrange. > > The explanation for why this error is not having consequences on my > plots is that the correct range for the (now logarithmic) axis will > always be set later on. > > > Regards > Achim. |
|
From: Achim G. <Str...@ne...> - 2017-11-08 18:41:29
|
Ethan A Merritt via gnuplot-beta writes: > That first line is not a legal command in version 5, or at any rate > it is meaningless. Well, that code is some years old and I haven't yet the need or otherwise gotten around to clue it in to the fact we're no longer using gnuplot-4.x on any installation. > If that command is actually doing something, that's a bug all by itself. I think not, but I've just stopped fiddling with it when I had the reproducer down to three lines. :-) > On the other hand, that spurious warning is generated even without > "reverse/noreverse" involved. I think the actual error is that > set xrange [*:*] turns on autoscaling but does not erase the previous > min/max. Since they were both negative numbers, "set log" complains. Yes, that sounds like a good explanation. > The code has a special check that handles the default axis range > setting [-10:10]. Maybe that check should be extended to cover all > cases of negative range limits? Not sure. But really I think the > problem is that "set auto" and "set range [*:*] don't actually clear > the previous limits. Unfortunately I suspect that the "refresh" command > relies on that, so the best fix is not immediately clear. I don't think I can currently help with that. As a workaround it seems that unset xrange; set autoscale x might do in our scripts, so I'm inclined to go with that for now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds |
|
From: Ethan A M. <sf...@us...> - 2017-11-08 23:40:12
|
On Wednesday, November 8, 2017 10:41:11 AM PST Achim Gratz wrote: > Ethan A Merritt via gnuplot-beta writes: > > > > I think the actual error is that > > set xrange [*:*] turns on autoscaling but does not erase the previous > > min/max. Since they were both negative numbers, "set log" complains. > > Yes, that sounds like a good explanation. > > > The code has a special check that handles the default axis range > > setting [-10:10]. Maybe that check should be extended to cover all > > cases of negative range limits? Not sure. But really I think the > > problem is that "set auto" and "set range [*:*] don't actually clear > > the previous limits. Unfortunately I suspect that the "refresh" > > command relies on that, so the best fix is not immediately clear. > > I don't think I can currently help with that. As a workaround it seems > that > > unset xrange; set autoscale x > > might do in our scripts, so I'm inclined to go with that for now. Here is a patch that I think will do the job. Since our SourceForge repository is currently in an undefined state (cvs is frozen, conversion to git has been done but may have to be redone if problems turn up), it may be a while before this change is visible in source downloaded from sf.net. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% diff --git a/src/set.c b/src/set.c index 2286ab362..c83d5905b 100644 --- a/src/set.c +++ b/src/set.c @@ -2790,10 +2790,17 @@ set_logscale() dummy = "x"; break; } - /* Avoid a warning message trigger by default axis range [-10:10] */ + /* Avoid a warning message triggered by default axis range [-10:10] */ if (axis_array[axis].set_min <= 0 && axis_array[axis].set_max > 0) axis_array[axis].set_min = 0.1; + /* Also forgive negative axis limits if we are currently autoscaling */ + if ((axis_array[axis].set_autoscale != AUTOSCALE_NONE) + && (axis_array[axis].set_min <= 0 || axis_array[axis].set_max <= 0)) { + axis_array[axis].set_min = 0.1; + axis_array[axis].set_max = 10.; + } + if (newbase == 10.) { sprintf(command, "set nonlinear %s via log10(%s) inv 10**%s", axis_name(axis), dummy, dummy); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
|
From: Achim G. <Str...@ne...> - 2017-11-09 18:22:36
|
Ethan A Merritt via gnuplot-beta writes: > Here is a patch that I think will do the job. > Since our SourceForge repository is currently in an undefined state > (cvs is frozen, conversion to git has been done but may have to > be redone if problems turn up), it may be a while before this change > is visible in source downloaded from sf.net. Thanks, I hope to have some time on the weekend to look at it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada |
|
From: Achim G. <Str...@ne...> - 2017-11-09 18:28:05
|
Achim Gratz writes: >>> I have to get to the bottom of it later. The only other difference to >>> 5.0.7 I've noticed is that the key box in some cases overlaps with some >>> labeling outside the main plot area. Again, I don't know exactly when >>> and why that happens, but I will eventually try to find out. >> >> Are these 3D plots? > > No, distribution plots, sometimes with reversed and/or logarithmic axes. > >> Have a look at the documentation for "set key fixed". > > I'll have to trace the same steps as outlined above, then I can be back > with more questions (unless it's already obvious by then). This happens because the timestamp position changes in 5.2.x from inbetween the axis labeling and a key box in the bottom margin to the actual bottom of the margin. I've confirmed that the position was inbetween the two parts from at least 4.0 onwards to 5.0.7. There is some space inbetween the axis labeling and the key box title that looks like a leftover from the previous behaviour. In addition poking around the key box settings has revealed a few other things that seem buggy and/or underdocumented, I'll make separate posts about them later. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada |
|
From: Achim G. <Str...@ne...> - 2018-05-08 18:38:44
|
Achim Gratz writes: > Achim Gratz writes: >>>> I have to get to the bottom of it later. The only other difference to >>>> 5.0.7 I've noticed is that the key box in some cases overlaps with some >>>> labeling outside the main plot area. Again, I don't know exactly when >>>> and why that happens, but I will eventually try to find out. >>> >>> Are these 3D plots? >> >> No, distribution plots, sometimes with reversed and/or logarithmic axes. >> >>> Have a look at the documentation for "set key fixed". >> >> I'll have to trace the same steps as outlined above, then I can be back >> with more questions (unless it's already obvious by then). > > This happens because the timestamp position changes in 5.2.x from > inbetween the axis labeling and a key box in the bottom margin to the > actual bottom of the margin. I've confirmed that the position was > inbetween the two parts from at least 4.0 onwards to 5.0.7. There is > some space inbetween the axis labeling and the key box title that looks > like a leftover from the previous behaviour. I've tried this again with 5.2.3 and the problem is still there. I'm attaching an input file and PDF output from both 5.0.7 and 5.2.3 that hopefully clearly demonstrates what I'm talking about. Nota that besides the position of the timestamp the key box title also changes font size. |
|
From: sfeam <sf...@us...> - 2018-05-09 17:20:12
|
On Tuesday, 08 May 2018 20:38:20 Achim Gratz wrote:
> Achim Gratz writes:
> > Achim Gratz writes:
> >>>> I have to get to the bottom of it later. The only other difference to
> >>>> 5.0.7 I've noticed is that the key box in some cases overlaps with some
> >>>> labeling outside the main plot area. Again, I don't know exactly when
> >>>> and why that happens, but I will eventually try to find out.
> >>>
> >>> Are these 3D plots?
> >>
> >> No, distribution plots, sometimes with reversed and/or logarithmic axes.
> >>
> >>> Have a look at the documentation for "set key fixed".
> >>
> >> I'll have to trace the same steps as outlined above, then I can be back
> >> with more questions (unless it's already obvious by then).
> >
> > This happens because the timestamp position changes in 5.2.x from
> > inbetween the axis labeling and a key box in the bottom margin to the
> > actual bottom of the margin. I've confirmed that the position was
> > inbetween the two parts from at least 4.0 onwards to 5.0.7.
Indeed. But was that ever intended or was it a long-standing bug?
Consistent placement of the timestamp at the bottom of the page was
an intentional change. The bug is overlap with some key placements.
I propose that the timestamp should always be at the bottom of the page,
and for 5.2.x when the key box is underneath the plot it should move up
in concert with the plot itself if space is added to accommodate the
timestamp. I acknowledge that behavior does not match any previous
version of gnuplot.
Placement of the key in 3D plots is even more complicated but
the combination of timestamp and "set key outside bottom center"
suffers from the same overlap problem as 2D plots in the current code.
Some fix is needed there also.
> > There is
> > some space inbetween the axis labeling and the key box title that looks
> > like a leftover from the previous behaviour.
>
> I've tried this again with 5.2.3 and the problem is still there. I'm
> attaching an input file and PDF output from both 5.0.7 and 5.2.3 that
> hopefully clearly demonstrates what I'm talking about. Nota that
> besides the position of the timestamp the key box title also changes
> font size.
Starting in gnuplot version 5 (I'm not sure exactly which point release)
the key title and the key contents can use separate fonts.
Your test script sets the key font but probably intended to set
the title font:
set key font "LiberationSansNarrow,11"
vs.
set key title font "LiberationSansNarrow,11"
Ethan
|
|
From: Achim G. <Str...@ne...> - 2018-05-09 18:34:08
|
sfeam via gnuplot-beta writes: >> > This happens because the timestamp position changes in 5.2.x from >> > inbetween the axis labeling and a key box in the bottom margin to the >> > actual bottom of the margin. I've confirmed that the position was >> > inbetween the two parts from at least 4.0 onwards to 5.0.7. > > Indeed. But was that ever intended or was it a long-standing bug? I have no opinion on that. I think I've already said that based on the documentation it would make sense for the timestamp to be always at the bottom of the page. > Consistent placement of the timestamp at the bottom of the page was > an intentional change. The bug is overlap with some key placements. Indeed. I would suggest that the space taken up be the timestamp should be taken away from the canvas size so that no element of the plot area will ever even attempt to encroach. I also think that this area should be given back to the plot if no timestamp is present, but maybe that decision would depend on what terminal is used. > I propose that the timestamp should always be at the bottom of the page, > and for 5.2.x when the key box is underneath the plot it should move up > in concert with the plot itself if space is added to accommodate the > timestamp. I acknowledge that behavior does not match any previous > version of gnuplot. That'd work for me. […] > Starting in gnuplot version 5 (I'm not sure exactly which point release) > the key title and the key contents can use separate fonts. > Your test script sets the key font but probably intended to set > the title font: > > set key font "LiberationSansNarrow,11" > vs. > set key title font "LiberationSansNarrow,11" I'm in the fortunate position of being able to change the script that produces the plots, so as long as I can obtain consistent behaviour that's OK with me. There already have been extensive changes when switching over from 4.x, so a few more changes to get from 5.0 to 5.2 don't scare me. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X