Soft-page-break versus style split options

[guruglenn]

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)

[ajlittoz]

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.

[guruglenn]

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.

[ajlittoz]

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.

[guruglenn]

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

I uploaded to the original post.

[guruglenn]

Added LO version to original post

[ajlittoz]

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.

[guruglenn]

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?

[guruglenn]

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.

[guruglenn]

So, after fiddling and fiddling, and discarding lots of ideas that failed, my present plan is to enhance my program that generates this data, to do its own widow and orphan control, and to use separate outline levels for left and right pages, and set the outline level 8 for even pages using a hidden paragraph prior to the end of the odd page (for simplicity, likely just one line before the visible header), and set the outline level 9 for odd pages using the actual visible header. And embed the whole thing in a borderless table inside the columns, so the numbers can be right aligned in the left column, and text left-aligned in the right column. Sadly, this is the sort of thing one would expect a word processor with all these features to be capable of, but with a number of features not functional when using hidden text, it seems it cannot be achieved.

[mikekaganski]

I do not see the problem in 25.2.5.1.

[guruglenn]

@mikekaganski sounds interesting, but which problem do you not see? The original problem where hidden paragraphs are not kept on the same page with next paragraph, even when defined that way? Or the one with frame positioning from headers and footers acting strangely when defined with reference to the page area? (which came up as a result of @ajlittoz suggestions?) Also, my LibreOffice (version above) claims to be uptodate when I tell it to check.

[mikekaganski]

@guruglenn

The original problem where hidden paragraphs are not kept on the same page with next paragraph

Ah - please ignore me. I was not careful enough to read that it was a problem of hidden paragraphs being on different pages. Yes, it’s there. I suppose, we don’t care about keeping hidden paragraphs with next - even when their properties are set. You may want to file a bug report.

[ajlittoz]

@guruglenn

use separate outline levels for left and right pages

This is utterly wrong! You will destroy the logical structure of your document, not speaking of unexpected (but absolutely normal) effects. When you request level 9 but there is presently none, you’ll get the most recent level 8 which is not what you want.

IMHO, you’re abusing the outline feature and uselessly complicate your design. Why don’t you simply assign the outline level on the keyword paragraph. Thus, the paragraph is no longer hidden and the problem vanishes.

@guruglenn

And embed the whole thing in a borderless table inside the columns, so the numbers can be right aligned in the left column, and text left-aligned in the right column.

Once again, you use a sledgehammer to do watch making. What you request can be done with a carefully crafter paragraph style with a tab stop associated with right alignment.

Always try to keep the document and its design as simple as possible (KISS principle). Tweaks you create without real necessity will turn on your back and result in instability and bad performance.

[guruglenn]

@ajlittoz

@guruglenn

use separate outline levels for left and right pages

This is utterly wrong! You will destroy the logical structure of your document, not speaking of unexpected (but absolutely normal) effects. When you request level 9 but there is presently none, you’ll get the most recent level 8 which is not what you want.

IMHO, you’re abusing the outline feature and uselessly complicate your design. Why don’t you simply assign the outline level on the keyword paragraph. Thus, the paragraph is no longer hidden and the problem vanishes.

So the document is just this concordance, so whatever it takes to get it to look right, is better than it looking wrong. Are there any other variables that can be similarly used, besides the outline variables? When I generate the data, I can make sure the variables both have the appropriate values at the appropriate time. And as long as I don’t try to generate an outline of my document, particularly one that has more than 7 levels, all will be fine.

@guruglenn

And embed the whole thing in a borderless table inside the columns, so the numbers can be right aligned in the left column, and text left-aligned in the right column.

@ajlittoz

Once again, you use a sledgehammer to do watch making. What you request can be done with a carefully crafter paragraph style with a tab stop associated with right alignment.

Always try to keep the document and its design as simple as possible (KISS principle). Tweaks you create without real necessity will turn on your back and result in instability and bad performance.

I would be glad to use something other than a sledgehammer, but you have offered no alternative that actually achieves the look I want, and in the presence of bugs or limitations, a sledgehammer seems appropriate to the situation.

I don’t recommend this as a general solution, but rather as a workaround to achieve the look I want, without writing a whole new wordprocessor that doesn’t have bugs or limitations, that force me to use a sledgehammer.

I’ll try to report this as a bug in due time, since it seems to be (at least) one. But my first priority is to get the document implemented, and prove that the little test case I made with the table actually works for the whole document, or if I find more bugs by using the sledgehammer.