TOC after update index only partially correct

English
, ,
#1

If I update indexes for the TOC some page numbers are correct, however some are not, I had to re-run the update index on the TOC around 3 or 4 times until the page numbers in the TOC look correct (right click on the TOC and selecting “Update Index”). Is this expected behaviour? If yes, is there a way to determine how many times I’ll need to run it?

I was trying to fix our TOC from a generated document using a short python script using the uno UpdateAllIndexes.
dispatcher.executeDispatch(oDocFrame, “.uno:UpdateAllIndexes”, “”, 0, ())

Once a user indicated issues I tried myself in the writer and as mentioned had to run it an addtional 2 or 3 times.

#2

“Ipdate Index” should bring the TOC immediately up-to-date. There may be some peculiarity in the headings. Are they styled Heading n? Have Heading n been customised? Are the incorrect entries always the same? If so, what is special with them? A user paragraph style?

Please edit your question to provide more information. If document is rather short and non-confidential, attach it to your question. If you can’t, try to make a reduced anonymised version still exhibiting the problem.

#3

@ajlittoz I’ll look into this, seems unusual that with multiple Update Index the TOC eventual is corrected fully

#4

Please provide a sample to test.

#5

@mikekaganski I spent a LOT of time yesterday trying to have something to share, however I’ve not gotten something yet; the document that fails is Confidential and I’ve tried to using a perl XML package to switch the text on the XML_TEXT_NODE nodes, however after I do that the update index fixes all index entries. I then tried to just make some minor changes manually to the XML to see if that would fix the problem but it does not.

#6

Shrug… You seem to have found a bug - but unless you file it to bug tracker, and provide something to work with, it can’t be even confirmed, let alone fixed. Hope you will manage to find such a neutral sample.

#7

@mikekaganski @ajlittoz Still working on it; In my switch text nodes as mentioned above and doing a diff between one that fails and one that works I see on the failed one that there is a text:soft-page-break/ which is absent on the one that works. Any knowledge on what triggers LO to add the text:soft-page-break/ and what they are for? When I view the document with the faulty TOC there is no page break at the location of the text:soft-page-break/; perhaps I can just delete them from the XML? Or is there a UNO command to cause LO to recalculate the soft page breaks?

#8

@mikekaganski Could the soft page breaks be an issue? When does LO add them (so I might be able to create a sample with the problem.)

Deleting the text:soft-page-break/ does not help as LO just adds them back in when I by UNO run the update index :frowning:

#9

I don’t know if that might be the issue. This; or specific characrers; or their count: whatever… I’d start with saving the problematic document to fodt to allow easy modifications. Made sure that the new document still has the problem after reopen. And then started replacing sensitive data one by one, testing the problem after each change. Find where it disappears and try to re-create the problem then…

#10

@mikekaganski converting it to fodt it does not have the problem, maybe I can use that as a fix; planning to discuss with a co-worker

#11

Just be aware of exceptions mentioned at LibreOffice and Version control - The Document Foundation Wiki , namely tdf#63642 and tdf#126772 , that show that fodt might miss some information present in odt.

#12

@mikekaganski FYI converting to fodt before the update index did not work on another doc with the same issue

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.