4_paragraph-fix.odt was a dead end. So I began again with 1_Programming-In-Python3.odt:

1. Opened 1_Programming-In-Python3.odt in AppImage 7.2.3.2
   (normal load, NOT 30%)

2. Used existing lines in Title page (currently styled as Direct Paragraph) to create styles Subtitle 1, (2, 3)
   (using f11 | Styles actions | New Style from Selection); thus no line on Title page now has Direct formatting

3. Shift+Ctrl+S (save-as) to 2_paragraph-fixes.odt

4. Changed Text Body style to "Below paragraph: 0.50 cm" + single line spacing
   (this matches the original pdf closely)

5. Changed default list + indent to Text Body Indent

My intention at this stage was to discover what it was that was freezing LO solid (and once froze the entire system solid). I *did* find it (a bug in 7.2.3.2, so not the original issue). First, a quick word about 'Direct Paragraph' style + Text-Boxes (TB) in H1, 2, 3 & 4 paragraphs:

The Direct Paragraph Style is the base style for all other paragraph styles. Thus, modifying that Style will affect every other paragraph in the entire document, which may (or may not) be what you want. I was also informed that using it directly as a Style throughout a document increases the processing load due to lack of caching.

Each Heading in the pdf contains a stylistic |||| for H1 headers, ||| for H2 headers, and so on. I used a TB to create these. I was advised to use a Frame instead. So what's the issue here?

TB can NOT be assigned a Style, whereas Frames CAN be assigned a Style. We are going to discover a very weird bug with these TB when we reach H2 edits. Frames also have a bad bug associated with them, but that is for later.

The next stage in these edits is to swap out each header TB for a Frame:

1. Each H1 TB was swapped out for a Frame
   (no problems)

2. Each H2 TB was swapped out for a Frame
   (I did it Chapter-by-Chapter; no problems until I reached Chapter 15)

3. The "Dialog-Style Programs" (p568) + "Main-Window-Style Programs" (p574) (ODT, not PDF) each have a TB that has a daeafb Colour applied to the Area (I do not recall applying them)

4. Changing the TB Area from Colour to None then showed the following option within menu:Edit: "Undo: Sort Shapes"

5. Attempting to Save the change produced the following Error (below), which then prevented any attempt to save the document

6. The identical change to the identical document under 7.4.7.2 showed zero problems

Wot a blooming nightmare.

The changes made to this point DID allow 'normal' 7.4.7.2 to open document with ordinary load after some short moments processing. Battered & bruised I continue.

I assume that a bug-report here needs to be to Debian. I could not find an easy way to do that (they use an auto-report which expects you to be using Debian). Any advice?

I'm not certain about the 'uncommon hardware' bit, but I accept your sentiments.

First time this has happened to me. Frightened the shit out of me when I got to the boot screen!

My situation at the end of the last post proved to be a false dawn when I restarted since the 30% load was back & did not go away. No changes at my end yet the bug was back. I carried on updating the paragraphs regardless.

Whilst still in the process of fixing all normal paragraphs (by changing them to being styled with "Text Body" rather than "Default Paragraph Style") I've just reached "Chapter 3 Collection Data Types" (page 113 out of 599) and, finally, the system load has switched yet again from being at a constant 30% (1 of the 4 cpu cores constantly fully occupied) to a more normal 2%.

Reaching this state has been my goal. I've done these changes before & reached this blissful condition on that occasion. In my ignorance I thought that all my problems were over until, after many more changes, the whole thing suddenly completely froze up.

On the previous occasion I had zero idea as to what change triggered the LO freeze. This time I am monitoring the results of the changes that I make much more carefully.

Wish me luck.

PS
I got Kernel 6.10 installed from bpo today & that had a harsh computer bug. I could not restart into the kernel because of some blasted error. I had to restart into the old kernel. Together with these LO issues it all seemed completely normal.

Thanks to rolfie & Babarosa for your responses.

I decided to go with an AppImage since that offered the opportunity to use a later version without changing any of the currently installed LO elements. It turned out to be not so much of a success (and then more of a success, see below).

I went through the following steps:

1. $ cd /usr/local/bin

2. $ sudo wget https://appimages.libreitalia.org/Libre … 4.AppImage

3. $ sudo mv LibreOffice-fresh.standard-x86_64.AppImage LibreOffice-24.8.AppImage

4. $ sudo chmod a+x LibreOffice-24.8.AppImage

5. $ LibreOffice-24.8.AppImage --help
   LibreOffice 24.8.2.1 0f794b6e29741098670a3b95d60478a65d05ef13

6. $ sudo cp /usr/share/applications/libreoffice-startcenter.desktop /usr/share/applications/loappimage-startcenter.desktop

7. $ sudo nano /usr/share/applications/loappimage-startcenter.desktop
   (I changed the .desktop name + all Exec lines to begin /usr/local/bin/LibreOffice-24.8.AppImage, but pretty much every else was left unchanged)

The new launch link was immediately within menu:Office | LO AppImage Start Centre & showed the correct LO version.

I launched 3_new.odt and GOOD LORD yes! I was able to navigate around the file & travel from top to bottom.

It was still troubling. LO was having problems with the page display at the bottom of the file. The number of pages showing in the Status Bar at bottom left, and also on each page, kept changing. In addition, Figure 15.1 (it is an image & can be viewed safely in the PDF) kept appearing at the top of the bibliography & also other pages, each one well out of place.

Since it seemed stable I asked for the file to be saved. Everything seemed fine & at a normal speed until almost at the very end, when LO & the screen froze. It stayed like that for some time & I had to force-close it. So, no change.

I did not make any changes to the file before saving.

2nd try:

Ran the whole thing again as to be able to discover the name of the image that kept appearing out of order near the bottom of the file (Fig 15.1) (it kept shifting in the display from page-to-page from moment to moment). I noticed that a single core (1 of 4) was active all the time. Also, that the LO version was GTK.

Then I noticed that the usage had dropped from 30% to a more-normal figure. I tried Save again & this time LO both saved it & also completed. I was able to shut the program down normally.

Whoo-hah! This version of LO is hardly working the way that it is supposed to with an ODT, but it seems that I may have use of the file back again, so many thanks to all who responded.

The following pages were also of assistance:

• https://forums.debian.net/viewtopic.php?t=158795

• https://www.libreoffice.org/download/appimage/

Update Nov 7: display fixes

Hi Babarosa.

Your post is the most hopeful for me so far.

I've tried "apt search libreoffice" & absolutely everything that came up is 7.4.7 (same as I currently have).

How did you install 7.6.7? Is it installed concurrent with 7.4.7 or instead of?

It sounds crazily ironic that v5.0.0 & v7.6.7 both can open this ODT yet v7.4.7 freezes solid.

I couldn't wait, so asked LO to start 3_new.odt, started my smartphone stopwatch & waited.

There are 4 cores in my Desktop machine, and I noted that one of them was 100% occupied all the time. Just once across the next 25 minutes I noted that processing had switched to a different core.

I had decided that I was willing to give it 25 minutes.

Too often I've been in situations where a process has gotten stuck & I could have waited for eternity & never had obtained satisfaction. This seemed like one of those.

After 25 minutes I force-closed it.

Thanks stargate, but I do not think that waiting for startup is any fix for this one.

Well, good news/bad news.

This morning I …

1. Restarted my computer

2. Checked that there were no lock-files in the ~/Python directory

3. Took a deep breath

4. Opened ~/Python/3_new.odt as only app

… and the computer did not freeze.

I kept watching for ~2 seconds, then realised that LibreOffice (LO) had frozen. I could move the mouse, but LO did not respond to any actions (no page movement, no scroll).

I tried closing LO from the desktop screen & got the "This program is not responding" message & asked for it to be closed down.

This is almost the identical behaviour that I experienced with 2_scratch.odt that caused me to try to reformat it as 3_new.odt. There is clearly some kind of issue inside the 2nd + 3rd ODT causing them to freeze. I wish that I knew where to start to find out precisely what.

The kernel has upgraded from 6.1.0-26 to 6.1.0-27 since I had the System freeze with 3_new.odt. Maybe that is a reason that my system is now safe from LO attack!

Well, many thanks to delgado for testing it out. I have a horrible feeling that I am now stuck with an untenable ODT.

In response to stargate: there are a number of Tables in this Writer document, but each is very small. There should not be any problem with a 700-page document (I sincerely hope).

The physical machine has 8 GiB of physical memory. That was a lot when I bought it, and is trivial now, of course, but together with swap-space on the HDD should be enough:

$ sudo lshw -C memory -short
[sudo] password for alexk: 
H/W path       Device      Class       Description
==================================================
/0/0                       memory      64KiB BIOS
/0/14                      memory      8GiB System Memory
/0/14/0                    memory      SODIMM DDR3 [empty]
/0/14/1                    memory      8GiB DIMM DDR3 Synchronous Unbuffered (Unregistered) 800 MHz (1.2 ns)
/0/1a                      memory      256KiB L1 cache
/0/1b                      memory      2MiB L2 cache

My almost-always-painless update process glitched today with a 404 when it tried to get the DEB. Immediately re-ran the (self-written) bash-file & it performed perfectly.

Since you are someone that ignores the advice that you are given, and yet expects others to keep giving help regardless, I'm backing out of this thread at this point.

use su - ("switch user to root") not sudo su. sudo by itself is "switch user to root one-time only".

This is the content of /etc/sudoers.d/README:

#
# The default /etc/sudoers file created on installation of the
# sudo  package now includes the directive:
# 
#       @includedir /etc/sudoers.d
# 
# This will cause sudo to read and parse any files in the /etc/sudoers.d 
# directory that do not end in '~' or contain a '.' character.
# 
# Note that there must be at least one file in the sudoers.d directory (this
# one will do).
# 
# Note also, that because sudoers contents can vary widely, no attempt is 
# made to add this directive to existing sudoers files on upgrade.  Feel free
# to add the above directive to the end of your /etc/sudoers file to enable 
# this functionality for existing installations if you wish! Sudo
# versions older than the one in Debian 11 (bullseye) require the
# directive will only support the old syntax #includedir, and the current
# sudo will happily accept both @includedir and #includedir
#
# Finally, please note that using the visudo command is the recommended way
# to update sudoers content, since it protects against many failure modes.
# See the man page for visudo and sudoers for more information.
#

For the record:

$ la /usr/bin/sudo
-rwsr-xr-x 1 root root 281624 Jun 27  2023 /usr/bin/sudo