TOC after update index only partially correct

asked 2019-08-27 14:28:53 +0200

melutovich gravatar image

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.

edit retag flag offensive close merge delete


"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.

ajlittoz gravatar imageajlittoz ( 2019-08-27 14:54:04 +0200 )edit

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

melutovich gravatar imagemelutovich ( 2019-08-27 15:12:03 +0200 )edit

Please provide a sample to test.

Mike Kaganski gravatar imageMike Kaganski ( 2019-08-28 09:49:51 +0200 )edit

@Mike Kaganski 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.

melutovich gravatar imagemelutovich ( 2019-08-28 09:57:55 +0200 )edit

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.

Mike Kaganski gravatar imageMike Kaganski ( 2019-08-28 10:18:47 +0200 )edit

@Mike Kaganski@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?

melutovich gravatar imagemelutovich ( 2019-08-28 11:47:47 +0200 )edit

@Mike Kaganski 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 :(

melutovich gravatar imagemelutovich ( 2019-08-28 14:16:04 +0200 )edit

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..

Mike Kaganski gravatar imageMike Kaganski ( 2019-08-28 14:37:59 +0200 )edit

@Mike Kaganski 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

melutovich gravatar imagemelutovich ( 2019-08-28 15:00:32 +0200 )edit

Just be aware of exceptions mentioned at , namely tdf#63642 and tdf#126772 , that show that fodt might miss some information present in odt.

Mike Kaganski gravatar imageMike Kaganski ( 2019-08-28 15:34:22 +0200 )edit