bugGNU Octave - Bugs: bug #63131, print of a plot is cropped if...

 
 

bug #63131: print of a plot is cropped if ResizeFcn had been mentioned.

Submitter:  Nicky McLean <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:  Need Info Assigned to:  None
Originator Name:  dinosaur Open/Closed:  * Open
Release:  * 5.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Sun 16 Oct 2022 10:41:28 AM UTC, comment #5: 

   Righto. I have updated to Mint 21 to suppress murmurs of "very old" and it has not been fun because the installer didn't recognise the "other" system. But I had warm backups and after disc clearing, and much floundering, eventually I attained a tidier dual-bootstrap system with Mint 21 and wunduhs XP.
   Via the Software Manager I found and installed Octave, a download of 80MB and I notice that it starts rather more swiftly than my previous installation which had been via Flatpak. This new version is 6.4.0 and Hic3 misbehaves, as described, and unreliably, as described.
   On looking again at the offerings from the Software Manager, I see that besides “Octave” (which I had selected because that was what I was looking for) there is also an offering “GNU Octave” which turns out to be for version 7.2.0 and involves the Flatpak scheme, and mentions that it requires 1,300MB to be downloaded. And over 4GB of disc space as well. Good grief! There seems to be no way that the stuff can be downloaded separately (as via the local library’s connection) so that I could prepare an installer on a USB memory stick as was done with the Mint 21 installation scheme. However, a friend has a fast internet connection, and he was able to download the stuff, though we couldn't figure out how to prepare/acquire an offline installation for my system.
   No matter, with the latest version on his system, Hic3 misbehaves also.

  In further testing/floundering I added some output generation and thought to remove the setting of units to "points" from the ResizeFcn, since that was done in Hic and surely need not be repeated. But not so. On activating a print command the ResizeFcn is invoked, and suddenly the units are "pixels" for gcf and "normalized" for gca.
  I specified "points" precisely because pixels are vastly different in size between screens and actual printers. My screens are 108 dots/inch (most screens run around 90), and a "point" is 1/72 of an inch.
   I don't understand why the hf values acquire decimal fractions, since my adjustments are by integer values. I think the plotting routines are enmeshed in confusion over the state of the units of various sizes at various stages and therefore also confused in the conversion of a plot displayed on the screen to something that might be printed.

   1) The plot displayed on screen is truncated (though not always), and, if the window is moved (no resizing) the ResizeFcn is not invoked but the plot becomes correct. Actually resizing the window causes stuttering reports from ResizeFcn, as expected.
   2) Even if the plot is not malformed, a print -dpng hic.png produces a file with a truncated image. The screen window also changes, to show the truncated image and possibly, changes size too. The ResizeFcn reports units other than the originally-specified "Points". Similar problems with .svg.
   3) A repeated run of Hic3 can produce different results. For instance, test runs on XP have just now refused to produce a malformed initial plot, but after the malformation induced by a print command, a re-run of Hic3 now produces a truncated plot to start with. The ResizeFcn is invoked if a plot window is opened, but if the plot window is left from a previous run, it is not invoked when Hic3 is reactivated. I note again the presence of the clf in the command file. Still further floundering could have reports made of "units", say, after every plotting command, perhaps detecting when the units are changed. Endless bunnies...

   I'm guessing that something is not being initialised, and the clf does not fully scrub the internal data structure...

Nicky McLean <dinosaur>
Fri 30 Sep 2022 05:34:30 AM UTC, comment #4: 

   Replacing the plot(t,y) with plot(t - t0,y) did indeed crush the misplotting of the half-hourly time series data (confirmed by the remark in Precision-issues on a resolution of ~45 mins delivered by single precision for current years), and this required a replacement of datetick to generate suitable annotation. Using a shift of subtracting two millennia would work for datetick, except that I often have data prior to the year 2000, and don't want confusions over apparently negative years so my trials with datetick were abandoned.
   I'm using an internet connection at a cost of around NZ$10/GB, which is cheaper than "broadband" if I refrain from watching movies - I prefer the big screen at a cinema. A new version of Octave costs some 600MB and takes a while to download, thus my laggardly approach. But, I'm contemplating Mint 21 (via a memory stick filled at the local library) and given that this would be a replacement installation, a new Octave would be an extension. This will take a few days to organise...

   Can any of you with more recent Octaves confirm that Hic3.m misbehaves or not?

   I chose "points" in my initial flounderings in the hope of some stability (screen/paper dot size being variable: my screens offer 108 dots per inch, but 90 is more common and was the case for the initial development's system) and yes, messing about with this could well cause trouble. I was tired after reducing GnashPlot.m to Hic3.m and so have not yet essayed variations to chase still more bunnies over the hill. For example, the sequence of plot statements can be a factor: before or after the data plotting? Specification of limits (if done or not), labels/titles/legend after plotting rather than before? And so forth.
   Likewise, my ResizeFcn can be simplified (now that lines = 1 always) and the global variable (and its weird existential confusions) could be done away with. Though in principle, the ResizeFcn could decide on annotation details given known sizes of the figure, and this would require access to date span information, probably via global variables. But this is an extension to defer.

Nicky McLean <dinosaur>
Thu 29 Sep 2022 02:21:31 PM UTC, comment #3: 

Also, for some convoluted reasons, printing involves resizing the figure, so your callback is being invoked at print time and may interfere (I see that it changes figure units and I would not be astonished that this is confusing the print system). Could you try disabling that callback when printing? You could for example define your own print.m which calls the builtin, e.g. :

function print (varargin)
  saved_fcn = get (gcf, "resizefcn");
  set (gcf, "resizefcn", []);
  builtin ("print", varargin{:});
  set (gcf, "resizefcn", saved_fcn);
endfunction

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Sep 2022 02:13:38 PM UTC, comment #2: 

TLDR, but some of your plots exhibit behavior explained in

https://docs.octave.org/v7.2.0/Precision-issues.html

Does workaround suggested there help you?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Sep 2022 01:07:05 PM UTC, comment #1: 

Both Octave 4.4.0 and 5.2.0 are very old and no longer supported.
A lot of changes have been done in the printing system since then.

Can you reproduce with Octave 7 or a build from the current development branch?

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 09:04:34 AM UTC, original submission:  

   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.

Nicky McLean <dinosaur>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53768:  Hic3.m added by dinosaur (2KiB - application/octet-stream)
file #53769:  GnashPlotResqueeze.m added by dinosaur (1KiB - application/octet-stream)
file #53770:  OctavePlots.7z added by dinosaur (301KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dinosaur (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-29 mmuetzel StatusNone Need Info
    2022-09-29 dinosaur Attached File- Added Hic3.m, #53768
        Attached File- Added GnashPlotResqueeze.m, #53769
        Attached File- Added OctavePlots.7z, #53770

    Back to the top


    Powered by Savane 3.9