Soft-page-break versus style split options

Using Windows version 25.2.4.3 (X86_64)

So I have style co-h9 which is used to define a text:outline-level=“9” value, and is marked “keep with next paragraph”.

Then I have style co-itm+ which displays the text value of outline-level=“9” and some other stuff. The split options for co-itm+ are Keep with next paragraph, on the “allow to split paragraph” is unchecked. What I wind up with, in .fodt output at a page boundary is the following:

<text:h text:style-name="co-h9" text:outline-level="9">ABSOLUTE</text:h>
<text:p text:style-name="co-itm_2b_"><text:soft-page-break/><text:span text:style-name="co-hno"><text:tab/><text:tab/></text:span><text:span text:style-name="co-cw"><text:chapter text:display="name" text:outline-level="9">ABSOLUTE</text:chapter></text:span></text:p>

So co-h9 and co-itm+ (shown as co-itm_2b_) are not separated by the page break, but the page break has been inserted inside of co-itm+ !! The effect of this is to separate the definition of the outline-level value to the page before it is used… but I’m using that outline-level value in a footer, so it is displaying in the footer a value that isn’t seen on the page. It seems logical to me that with “allow to split paragraph” unchecked, that a soft-page-break shouldn’t be inserted within the tags for co-itm+, but that it should be forced above the co-h9 style, because of the “keep with next paragraph” settings.

What am I missing?

I note the co-h9 is rendered as text:h and co-itm+ as text:p, and am not sure if that matters or should matter to this issue.
test.odt (57.6 KB)

Attach your file so that we have the whole story in your styles.

Word “footer” hints to a bad usage as text flow properties are nonsense in footers and headers.

I don’t find the feature to attach files, neither here in reply mode, nor in the edit capability of the original post, which would seem like a better place to put it. I have carved the file down from 188 pages to 2 pages which demonstrate the problem.

In the footer, I’m just using the outline level value to be displayed, for the last outline value on the page… but positioning it in a frame at the top right of the page.

When you edit a post or write a new one, you have a toolbar above the entry area. The Upload button is the 7th from left. It looks like a mail drawer with an upward arrow.

Thanks. Too many different forum packages, too many different icons.

I uploaded to the original post.

Added LO version to original post

I have not the same layout here: LO 25.2.4.3 under Fedora 42 with KDE Plasma desktop, because I have no Times New Roman and this font is substituted, resulting in different page breaks.

I tried to simulate different location for page break by changing page height by 0.1cm steps and I succeeded in having a distortion between last H9 and frame display.

I think this is caused by the Hidden attribute in co-h9 style. Hidden paragraphs are removed from final output. They are “transparent” to text flow. However, when Writer computes what is shown on screen, all the more when View>Formatting Marks is enabled, these hidden paragraphs occupy space and their text flow properties (here Keep with next para) are taken into account (ignoring Hidden!). This creates the discrepancy between the real position of the page break and the dotted-underline display of the hidden paragraph.


It looks to me your sample is some kind of alphabetical index you painfully build manually.
The same could be done automatically and this would eliminate the poor tricks you implemented.
The idea is to rely on the *Alphabetical Index* feature where you attach an index entry (or several if you need several indexing keys for the same paragraph like *light* and *abide* in the first title). The title is entered in the *Entry* field and the key in *1st key*.
The alphabetical index is automatically generated and you only need to customise *Index 1* and *Index 2* paragraph styles. You can also modify the *Structure* line to reverse positions of page number and text. The *Alphabetical Index* can also be laid out in columns, removing the need for a user-inserted section.
There are also several problems in your document.
  • Why a section?
    Since you have create mus-page page style, you could have configured it for 3 columns. A section is legitimate only to get a different layout within a page.
    And the fewer you have sections, the better performance you get, not speaking of document stability.
  • Improve your paragraph styles
    You have associated co-itm and co-itm+ to cover different semantic roles while keeping a common layout: a running paragraph and a key heading. However, you can’t rule out that a title will exceed the available column width. In this case, line wrap will no longer correctly align your text.
    • Modify co-itm as follows:
      • Indents & Spacing: Before text 0.5cm, First Line Indent -0.1cm
      • Tabs: remove your tabs and add one at -0.1cm for right alignment
    • Modify co-itm+:
      • Indents & Spacing: erase inherited First Line Indent
      • Tabs: delete inherited stop at -0.1cm
    • Delete the tabs you typed before all fields in co-itm+ paragraphs; your key automatically aligns.
  • Use a frame style
    You have manually positioned your frame containing the last key for the page. When I changed page height during my experiments, your frame was no longer at top of page text. Create a dedicated frame style (derived from Frame) with the following properties:
    • transfer or set Size and Borders as needed
    • Anchor To paragraph
    • Position Horizontal Right to Page text area, *Vertical Top to Page text area
      The frame will now remain at top right of your text no matter how you change page size, margins, header and footer areas. But take care there is absolutely no direct formatting on this frame (in othe words, never move it or resize it with the mouse).

There are probably other issues but these are the main ones I can diagnose from the sample. Above all, think thoroughly about your document structure (see my suggestion about *Alphabetical Index*). Also, your styles (names) are too visual-rendering oriented, i.e. your names tend to reflect the final look instead of the significance of the data they apply to.

Thanks much for your analysis and suggestions, this was my first attempt to make a concordance (hence the co- names); and the focus was, indeed, on the visual rendering rather than the semantic, and although the itm, itm+, and hdr entries were somewhat semantically named, the h9 was clearly just a placeholder for the outline level 9 data. Note that my concordance is a different concept than the LibreOffice “concordance file” used for automatically searching a document for terms to place in the alphabetical index. Also, it should be noted that my numbers (co-hno style) are not page numbers, but more like paragraph or section numbers.

The document (of which I shared a tiny subset), was generated by first creating, in Writer, the expected styles, fiddling around to discover the ability to use the outline-level as a way of generating the footer (postioned to the top) for the last entry in the page (when it works). Then a python script was used to generate 180+ pages of entries in the format of the fodt layout, and opened up in LibreOffice. It worked pretty well, except for the issue I raised here. The source data is not in a LibreOffice document, which may impact the ability to use the “Alphabetical Index” feature. More about that below.

It does seem that the issue I raised is related to how the hidden paragraphs are handled (or conceivably mis-handled) by LibreOffice.

I’ll respond to your “problems”:
The section was used because of other document experiments I was doing with other data, which had a variety of multi-page data formats, some of which overlapped on the same page. I didn’t find any reference to using sections only to get different layouts on the same page, although it is obvious that can be done. It seems your recommendation is to use different page styles for different parts of a document that do not overlap on the same page. I think I overlooked the ability to define columns within a page style, maybe because some of those other documents with columns had titles at the top of the first page, that wanted to be constrained only be the page size, not the column size, and that led me to using sections to define columns.

paragraph styles: The length of the entries will always fit on a single line in the column, they were manually shortened to guarantee that after getting the data into Writer. So there was no concern to improve the formatting if the line should be longer: rather the line was shortened. This is intentional and desired, not because of inability to alter the format of those paragraphs.

Frame style: yes, the frame positioning was an annoyance, but only had to be done when doing the initial setup. But then, when I discovered a need to add the trim marks you can see in the corners of the pages for the publisher, I had to readjust those settings. I’ll work on improving that per your suggestions.

Now to your main suggestion, the “Alphabetical index”. When I briefly looked at the indexing features of Writer, it seemed that they were quite flexible, but were designed to index a document that exists in Writer format, by annotating the various entries at their locations on various pages. Two things I’m concerned about for the Alphabetical index: can I control the numbering, and how can I generate the footer containing last entry? I’ve read the page about creating the Alphabetical Index, and creating the entries, but I don’t immediately see how to achieve those things, even if I build a throwaway document, and attempt to create an alphabetical index on it, to get the pages I need. Could you create a sample of the how you would use the feature to get the style of results in my sample?

Hmm. Defining and using a Frame Style, anchored to a paragraph in the header or footer, but positioned to the Page Text Area as you suggested, resulted in 4 strange effects not seen with the previous absolute positioning that I had been using.

  1. The Page Text Area apparently being defined as the Header or Footer text area, rather that the main flow of the page.
  2. the width and height dimensions seemed to be swapped, or some strange limits placed, because the word was broken into two character stacked fragments instead of being on a single line.
  3. lack of borders on the sides of the frame that were defined to have them.
  4. the frame defined to be on the right side of the page, and defined in the footer, actually appeared on the left side of the page.

I’ve attached a screenshot of a fragment of the bottom of the first page, and top of the second page, of course my header is vary short in height, so only the grey background of field is visible there to show the frame position.