The origin of the problem is in the clumsy (no offence intended) imitation of chapter start layout of the original book.
Presently, your chapter headings are styled Heading 1 with a LOT of direct formatting to force resemblance to the goal. Tools>Heading Numbering requests numbering (with Chapter prefix and ; suffix). Direct formatting then removes the number because you want the number separated from the heading at top of page. You send this number into the header (where it does not make sense because a header is supposed to contain only “static” reference-able data not participating in text flow). You also want a kind of chapter TOC aside the number. Once again you send this mini-TOC in the header as a drawing object (this is less harmful structurally speaking because it is static data) but you should avoid drawing objects as much as possible, all the more when they are related to text.
What happens is your DF (=direct formatting) cancels the existence of chapter number. Therefore, whenever you reference level-1 heading number, you get void value, simply because the number does not exist.
You attempted to compensate by using a number range (Drawing) which you dedicated to chapter numbering. Unfortunately, a number range is not the same as list style (which links together 10 number ranges with hierarchical reset) and this creates more problems later than it solves.
In addition, you need one page style per chapter in order to insert all your chapter-specific manual data. If you could cross-reference through fields, a single first-page chapter page style would do the job for all your chapters.
Proposed Fix
-
Reintroduce the number into the heading
Use Heading 1 as usual: let the paragraph bear its number taken from internal list style Heading Numbering.
Separating this number from the heading itself is done in Tools>Heading Numbering, Position tab where you request a New Line after the number.
-
Managing heading background
You want no background below the number and a coloured background below heading text. This rules out Area in paragraph style because it applies to the whole paragraph (number + heading). Consequently, Area is reverted to None and the background will be done with Highlighting.
Suppression of number highlighting is provided by a dedicated character style applied in Tools>Heading Numbering, Numbering Tab. I named this style Chapter Number. It defines font size, weight and variant (it is quite tricky to suppress italic coming from the paragraph style, but it is doable through a “magic stance” as can been seen in my sample) and None highlighting (has to set explicitly).
-
Forcing highlighting from margin to margin
Highlighing is normally done only on characters which means it stops at last character of heading. The trick is to create “fake” text up to paragraph right indent. To make things automatic and simple, a tab stop is added at right margin (17 cm, remember to adjust if you change page margins because LO allows only to create stops relative to left indent).
Then, headings are terminated by pressing Tab. This will have no effect on TOC(s) because non-text characters are converted to spaces when TOC is collected.
When headings are longer than one line, they wrap but we are confronted to the same issue. Generally long heading are mutually wrapped to achieve better visual effect (or to comply with grammar rules, such not separating an adjective from its noun or a preposition from its “target”). This means that author adds a manual line break. Instead, press Tab first before line break.
-
Horizontal line below chapter number
Sorry for this one. I tried several tricks based on border but I did not success. All I get is a stroke with the same width as the number without spacing with heading highlight.
If this is not a stringent requirement, drop it.
-
Chapter TOC
This chapter TOC is a “side annotation”. The adequate tool is a frame. Inside the frame, I used cross-references to Heading 2 paragraphs.
I did not use the chapter TOC feature because it repeats the chapter heading which, presently, can’t be suppressed. It is a shame since it would have completely automated the process.
I created a frame style Chapter TOC anchored to right paragraph edge, slightly below top, with width limited to 8 cm, height auto-adjustable.
I hope your chapter TOCs won’t ever require too many line, otherwise it interacts with the heading and breaks the nice presentation. This can partially be handled by modifying Chapter Number character style Borders tab to increase bottom padding. This is a global setting (no DF possible here) which must be tuned for the most demanding chapter TOC.
Inside the frame, everything is paragraph styles Chapter TOC which is associated with list style Chapter TOC (to prefix every heading with BLACK CIRCLE). Indent is set to correctly line wrap and align below the first line text (contrary to text boxes).
Note that there is a “Reference error” line in the chapter TOC because I referenced an Heading 2 before I deleted text to make an attachable document (below the size limit).
My 2-cents advice is to “package” together an empty chapter heading with its side TOC frame in an AutoText entry to make it easy and user-friendly to create a new chapter heading.
-
Chapter start page style
Since no topic text needs to be sent in the header now, you can use the same page style (to be created) for all chapter starts. I leave this as an exercise.
There will be no header. Adjust top margin to position chapter heading where you want it.
-
Figure caption
The previous corrections have re-enabled the standard behaviour of heading numbering. The chapter number has become available to number ranges and Figure displays again the chapter number without the need for fake Drawing number range.
I checked by adding a second caption to Fig 1.1 before realising that the Figure field already contained the expected chapter number. This second caption is of course number 1.2.
Other severe pending problems
I suspect these problems come from the initial acquisition process of the text. Did you use an OCR program (perhaps applied to PDF) which would have introduced DOCX or “alien” formatting primitives?
Figures
I deleted text at end of privately sent document and saw that the number of pages did not decrease. This is a symptom for badly anchored frames.
Effectively, all your frames are anchored To page which means they remain attach to a designated physical page, causing many intermediate undeletable pages. I had to delete them manually.
You should design an adequate frame style for them. It is obvious they share the same properties and a single style can do the job. Take special care to anchor this frame style To paragraph.
I remind you that anchor and position are independent settings. A paragraph-anchored frame can be position anywhere in the page. So choose sensible parameters. Pay attention to Allow overlap. Untick it so that multiple conflicting frames in the same page can be automatically repositioned by Writer. I don’t understand why developers chose to tick it by default, which leads to numerous user complaints about positioning.
Above all, refrain from changing frame position manually with the mouse. Frames are extremely highly (sorry for pleonasm but I can’t emphasise enough the risk here) sensitive to DF. And this DF form is very difficult to remove (making frame styles rejected by most users).
Tables
After understanding the problem with frames, I faced another issue with **tables**. The tables behaved exactly like page-anchored frames and, in addition could not be deleted with
Del.
Apparently, they are page anchored though there is no UI for it nor parameters in properties. The only way to get rid of them is right-click + Delete>Table. I did that for a few of them but was too lazy for the rest.
Sample
Here is a reduced sample with my “fixes”: 2_paragraph-ajl.odt (312.5 KB)
Study the new styles.
UPDATE 2024-11-24
Tables
Your tables are contained in a frame with the exact size of the table. And since these frames are anchored to page, they are the culprit for the “persistent unmovable tables”.
There is no point jailing the tables in frames unless you want some text aside the table. And in this case, the frame will likely be anchored to this paragraph.
I suppose that the frames were used to reduce table width (so that they don’t extend from margin to margin). This can be done more comfortably through table properties (and decreasing thus the number of frames will make Writer more reactive).
A caption can still be created for the table. Indeed, it is less strongly attached to the table (because it is no longer in the table frame) but you can force the table to Keep with next paragraph to make table+caption an atomic block.
The only drawback I see is the impossibility to position the table anywhere in the page. It is now part of the text flow, meaning it can cause white space at bottom of page before the table at next page. I seem to remember having found settings which allow to have the paragraph on a page and the frame on the next one. The combination of settings is tricky but stable. The context is also important. It works only if the paragraph is the last on the page. We may talk about this later in a separate question or privately.
