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

[Nicky McLean]

Follow-up Comment #5, bug #63131 (project octave):

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


    _______________________________________________________

Reply to this item at:

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

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