[Octave-bug-tracker] [bug #63131] print of a plot is cropped if ResizeFcn had been mentioned.

[Nicky McLean]

URL:
  <https://savannah.gnu.org/bugs/?63131>

                 Summary: print of a plot is cropped if ResizeFcn had been
mentioned.
                 Project: GNU Octave
               Submitter: dinosaur
               Submitted: Thu 29 Sep 2022 09:04:34 AM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: dinosaur
        Originator Email: 
             Open/Closed: Open
                 Release: 5.2.0
         Discussion Lock: Any
        Operating System: Any


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 29 Sep 2022 09:04:34 AM UTC By: Nicky McLean <dinosaur>
   Having prepared a plot and found it good enough, a command such as print
-dpng p3ChopPlot.png is intended to provide a “portable network graphic”
format file that can be kept or even printed on actual paper. However, the
result is a file containing only the top left quarter of the plotted figure,
further, the screen window showing the figure also shows the now cropped plot,
as depicted in file p4ChopPlot.jpg. The same happens if the .svg format is
tried.
   Should the plot-producing command file be re-run, the figure is not altered
and the cropped result remains. This despite the command sequence figure(1);
clf; as the plot is prepared. Manually issuing a clf does clear the figure,
but on re-plotting the cropped result re-appears. If the plot window is closed
and the plot command re-issued again, a new window is re-opened and all is
well. Until a print attempt. Sometimes, after a print command, the figure
window vanished yet its Figure 1 entry in the system tray remained. Poking
that causes the tray entry to seem to flash up to where the window had been
(an animation feature), but, no window appears despite pokes of Minimize and
Maximize. But this is occasional.
   During all this there were frequent crashes, though with no apparent
provocation. On some days, all would go well, on others Octave would crash
repeatedly, sometimes even as the first plot was being prepared, other times
on later plots. The CLI activation of Octave seemed less susceptible than the
GUI, but both could fail. If one failed repeatedly, perhaps the other would
succeed. Certainly, the startup sequences differ as the GUI interface is
noticeably slower to appear. Similarly, the computer start sequence could
differ – perhaps I login as soon as the offer appears, or, wait a little for
disc activity to ease. One day on restarting the computer, the first plot was
shown as a repeat of the truncated layout just as it had been when I had given
up on the previous day, this before any print command had been attempted. But,
I may be confusing events...Whichever, once the first few plots had survived,
a later crash was less usual. Formative causation? Winnowing of the weak?
   Windows prepares a crash report, but there seems to be no way to capture
the text as its display window does not support copy&paste. The message merely
vanishes to microsoft.
   This is Octave 4.4.0, the last version available for windows XP, which in
32-bit I am using because of software compatibility issues too tedious to
relate, and, the emulation of XP offered by windows 7, for example, didn’t
work properly. I am not sorry to not wade further along the path of bloat
provided by later windows versions.
   However, this is a dual-boot system, and via GNU/Linux Mint 20.1 64-bit I
can run Octave 5.2.0 and the same damaged plots appear. But not the crashes,
or at least, not many and not in recent recollection. With earlier versions of
Octave, not only was the post-print plot cropped, it was also defaced by many
lines joining a point to other positions outside the displayed portion. This
was in the .png file, not in the displayed window. I think.

   I am confronted by hordes of data series that may or may not be related,
and to assess matters, a horde of plots could be helpful. The candidate data
series run from a day’s data to decades - and with sunspot data, even
centuries. Experience showed that plotting no more than two dozen figures at a
run (some with more than one data series) avoided choking. The next stage
would be to reposition the various windows (across two screens), adjust their
size to better suit their x-span, and then try to make some sense of the mob.
When the size of a window is changed, the plot within does not follow the
change unless there is a ResizeFcn specified... Octave appears to be likely to
crash during such re-size attempts – though it may just be that a burst of
plotting activity is being provoked as when the plots are being made and
crashes happen then. If the figure being resized is the last figure plotted
(and thus the current figure), the contents are re-plotted (usually?) to the
new size, but this seems less likely to happen for the other figures produced.
Notably, the ticklengths are enlarged to suit the width enlargement, but on
re-running the plot commands (this time with the windows in place, not
creating them) they revert to the desired small size.
   Various difficulties have been encountered. Half-hours (as for a day’s
data) are not easily resolved as a part of matlab daynumbers by the plotting
process, resulting in maimed plots as in p1BadPlot.jpg  By converting the
likes of plot(t,y) to plot(t – t0,y) where t0 was the time of the first
day’s start, the plots were correct, but datetick could no longer be used to
annotate the x-axis. The result is p2GoodPlot.jpg
   In adjusting the plotting to employ t – t0 rather than t alone, I
remembered to change the stairs command as well as plot, but failed to
remember that the line command was also for plotting. The resulting plots
lacked the higher values in the sameish way as earlier plots, and this led to
the explicit use of ylim and the discovery that items plotted with
HandleVisibility set to off (as a part of deciding which items would be
described in a legend) did not contribute to the determination of the plot
limits.

   A systematic inspection of the 1,200 lines of GnashPlot.m with a view to
extracting the commands that would be used for the simple data file
Asample.csv led to Hic3.m, which exhibits the plot cropping, without the
organisational complexities attempted by GnashPlot. Notably, the sample data
could be replaced by some ad-hoc numbers (so, no need to read Asample.csv),
and there was no need to plot the daily averages stepwise so they could be
dropped as well as the associated HandleVisibility juggling. Similarly, the
complex annotation of the time axis could be dropped. Indeed, all annotation
could be dropped.
   As well, the loss of datetick had forced a re-assessment of the x-axis
annotation, where there had been some confusion over whether to count the tick
annotation as a line of annotation text as well as the xlabel line, itself
possibly being more than one line high. The result was that there now would
only ever be lines = 1. Some further co-ordination is indicated. In principle,
the ResizeFcn could assess the axis size and select suitable tick marks and
annotation given the available spacing, but this would require more
co-ordination, and I first want things to work before improving them...

   However, file Hic3.m along with its associate GnashPlotResqueeze.m
demonstrates the problem:
      Hic3
      print -dpng a.png 
produces a cropped figure and a cropped image in the output file. Note that
since the problem state can persist from one plot to another (despite clf),
successive tests should be done after re-starting Octave, while clutching at a
straw – though this may not be enough..
   On scowling further at Hic3, the most peculiar line drew attention, and,
commenting out line 30, set(gcf,'ResizeFcn','GnashPlotResqueeze'); avoids the
cropping (though, resizing fails) and .png or .svg files are good. But, sized
for paper sheets, not suitable for looong thin timeseries plots, which becomes
another bunny to chase.

   This had not been a problem with matlab: on adjusting any plot window size,
the plot within would be re-plotted to the new size (given the ResizeFcn),
and, the production of a .png file worked (via File>Save as), and in the same
length/height ratio of the window, such as wide and low. No .svg format
though.
   A test run of Octave of the full plotting command file run for a more
substantial data collection but with the ResizeFcn suppressed produced a good
plot (after resizing the window and re-plotting), but the File>Save as
defaults to an otherwise unknown .ofile type, and using the .png type produces
an aspect ration resized for paper. The desired result from a screen grab is
file p5Albany.jpg; a pity that yellow is so faint. Hope that the absence of a
crash during this boded well for the future was dashed by a crash just as the
screengrab was done... Ah well. It will be better with linux, but switching
systems is a drag on the patience.
   A test run via linux produced file Screenshot from 2022-09-29 20-44-46.png
(with the figure’s re-sized aspect ratio), and the finer lines confirm that
the bars for each day’s values (max to upper quartile, lower quartile to
min) are slightly offset from the middle of each day for the two data series,
as is intended so as to not overwrite each other. This image is from figure 2;
figure 1 for its data showed the cropped top left quarter as if a print
command had been issued. It had not, but the last run of Octave on linux the
previous day had indeed demonstated the problem – via Hic3.m producing
figure 1. So, even after a computer restart, the problem can persist on linux
also. Despite the clf command.






    _______________________________________________________
File Attachments:


-------------------------------------------------------
Date: Thu 29 Sep 2022 09:04:34 AM UTC  Name: Hic3.m  Size: 2KiB   By: dinosaur

<http://savannah.gnu.org/bugs/download.php?file_id=53768>
-------------------------------------------------------
Date: Thu 29 Sep 2022 09:04:34 AM UTC  Name: GnashPlotResqueeze.m  Size: 1KiB 
 By: dinosaur

<http://savannah.gnu.org/bugs/download.php?file_id=53769>
-------------------------------------------------------
Date: Thu 29 Sep 2022 09:04:34 AM UTC  Name: OctavePlots.7z  Size: 301KiB  
By: dinosaur

<http://savannah.gnu.org/bugs/download.php?file_id=53770>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63131>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/