Writer endnote collection mix-up

The collection of endnotes are mixed up, which changes in time.
I use LibreOffice 7.2.3.2 on Ubuntu 20.04.

I have a document of 349 pages and use 53 endnotes. To give the reader extra information, I added the pagenumber, using cross-section, where the endnote is used in the text. Beside that I have a good view of the sequence of the endnote. The pagenumbers must go from low to high.

Also because the number of endnotes are large, containing 4 pages, I use grouping, for the endnotes. Using Grouping endnote by chapter for LO 7.0 - English - Ask LibreOffice

Multiple mixed up:

The collection of the endnotes are mixed up. Both in the group, and for the endnotes them self.

Also the page style is mixed up. I use specific left page and right page. But the left page style is also used for the right page. Sometime a blanco page is on the right side.

These mixed up is not stable. When refreshing the index, it change. If closing and opening the document, is changes. And even when I close and open LibreOfiice it changes. But not always.

My question are:

  • Is this a know issue?
  • How can this be solved? An ugly work-arround, I do not mind.

Can’t tell without a sample file. Can you create one (5 pages max, including the notes) still exhibiting the issue? If so, attach it to your question.
You may have messed up page styles configuration. Also, changing page style in endnotes is quite tricky but doable.

Step by step I reduced the number of pages. Now I reduced it to 83 pages, and the sequence of the collection of endnotes (with 31 endnotes) is good. The page format for the first and endnote collection page is “Left page with footer” which is ok. The second, right collection of the endnote page is also “Left page with footer” which should be “Right page with footer”.

Have you configured Next Style in Organizer of both page styles?

Yes I have. And in the past, when the size was smaller, it did work, including switching from right page to left page.

A thorough analysis of your styles and formatting is needed. If you can’t reproduce the issue with a “small” document, send the smallest you can reduce to as an attachement to a private message. For this, click on my name, then on the Message button. Size limitations may apply. If this doesn’t work, send a private message with your email-@dress and we’ll see how to proceed.

Thanks for your effort. What I did was copy the folder, of my .odm and detail document, to a test folder. There I reduced the number of pages, step by step, and see the results. All failed, until I reached 83 pages. The collection of endnotes and the sequence are with this number ok. But not the page layout (right and left pages).
So I went back to the copy version which where I did not delete so many included subdocuments. half to my surprice, the sequence of the collections of endnotes are know correct. “Half to my surprice”, because I noticed earlier It is not stable. Which means results are not reproducible. Even for me, on the same computer, with the same document. So the first thing to do, I think, make it stable. Make it reproducible. Do you have any suggestions?

Mmmmh … Without any clue about your writing habit, it just like looking into a crystal ball. I’d suspect some interaction between manual formatting and styling. On long documents, if you don’t stick to a very strict method banning direct formatting, you’re doomed to experience such “surprises”. Character styles are often neglected because keyboard shortcuts for bold, italic and others appear more “intuitive” (because M$ Word doesn’t offer any alternative). One note may contain some direct formatting which creates havoc.

That indeed might be the case. Which is, for large documents a disaster. I am human, and human make mistakes. In software development you have a compiler, which not only fails, if you have a programming error, but also check give the line and the kind of error. So the programmer is able to correct it.

If manual formatting may cause such a disaster, there should be a check to show, at detail level, where manual formatting occur. So me, as user as human, can correct it.

But I doubt if that is the only error. Possible manual formatting does not change when just closing and opening the document. But for me it does.

If you want me to give detailed analysis, privately email me so I can give you my real @dress. You can after that send me your document. But my mail provider limits attachments to 10MB. Bigger sizes can only be exchanged via ftp or transfer service.

I can not give you more detailed analyses, then what I did. I can send you the full document info, including the template and make a zip file of it. If the result is bigger then 10 MB, there is a save way to transfer. I will let you know by mail.
Do you think, this full data can give you info to find the cause?

My first effort is to make this case producible. If it is not reproducible, you can find a solution. I use it, and for me it is not. This has no use.
Or may be it is, for the first time I open the document it is solved. But not for the second time I open the identical document.

A work-arround is also ok for me. Like copy the complete collection of endnotes, edit and correct it in a separate document. And past is at the end of the .odm file

At least I can check if this is intrinsic to the document or due to a general cause.

For those of you interested, I suspect a bug in the way LO Writer handles endnotes.

  • Assigning a non-default page style in Tools>Footnotes & Endnotes
    This is needed if you want an alternation between sophisticated left and right layouts.

    • Alternation doesn’t occur although parity is observed: only the initial page style is used and a blank page is inserted every other one and on the wrong side!
    • In addition, though I couldn’t determine the exact circumstances, after the count of endnotes exceeds a limit (between 75 and 100), some sequences of notes are listed in reverse order. E.g. the first ~75+ notes are in ascending order, then you get several dozens in reverse order, then again a block, which should have preceded the faulty one, in ascending order.
    • Notes are displayed not in the contents area of the page style but in the footnote area
    • The bottom margin height, as defined by the page style, is ignored on pages 2+ as is the top margin height on page 1.
  • Using built-in Endnote page style
    Non-default top and bottom margins are ignored or randomly accepted. This may cause clipping on notes (they are set in the contents areas beyond page limits and this is clipped to contents area). These custom margin may also cause appearance of descending order blocks.

Bug report at fdo#147963

I send my complete source, separately, because it contains confidential information to @Ajlittoz. It seems indeed a bug. But also I used more direct formatting then I thought. The document was complex, which triggers the bug. For programmers this kind of bug is hard to find. To simplify the document, I followed ajlittoz advice:

First I used the custom page style “left page with footer” and “right page with footer”. That did not work, I should use the default “Endnote” pagestyle, with a different left and right page footer. It helped, page footers are OK now.

Vertical spacing (just a few empty lines) seems to be direct formatting. I removed them as much as possible, and made a paragraph style of it. In rare cases, where a paragraph style would only be used once, still I used (most for vertical spacing) still direct formatting, which was Ok according to ajlittoz. The endnote collection improved, only the last page was mixed up.

In my document I had many single page with chapter, level 1, heading, with naming syntax: x00_00_y as a sub-document in my .odm file.

Next tip of ajlittoz was:

I think that you shouldn’t create sub-docs for the x0_00_y because they only contain one line, the chapter heading. This uselessly puts strain on Writer. To replace the sub-doc by some text:

  • click on the existing doc in the Navigator (the view where you have the list of sub-docs and text components of the master)
  • click on the down-arrow of the Insert button and choose Text

You now have a text “section” before the sub-doc. Double-click on it to go there. Enter the chapter heading with the required style.

  • You can now erase the x0_00_y sub-doc in the Navigator.

That solved the problem completely. LO had a bug, this should not happen, but direct formatting increase the risk. Which only can be seen, at the very end, when the document is almost ready. Especially with large documents. So, I agree completely with ajlittoz, reduce direct formatting as much as you can, preferably not one.