Possibly related to bug 34121 ?

The problem is more difficult to live with if your document contains hidden paragraphs that are hidden from PDF or printed outputs.

I have this writer document template which contains conditionally hidden paragraphs which are hidden from PDF and printed outputs. 

Suppose I have a heading in page 4 and page 3 is full of hidden paragraphs (hidden from print / pdf only). This heading will be included in the TOC and page number would read 4. Now I enter a cross-reference to the page number of this heading anywhere within the document. This also would read 4 (for now). Then when I print this document the TOC would say that the heading is still in page 4 and the cross-reference would say its in 3 which is correct by the way.

The only work around I have is to instruct my users to disable display of hidden paragraphs, update TOC and then print.

Good idea :-)
Looks as an easy hack?

*** Bug 89596 has been marked as a duplicate of this bug. ***

*** Bug 96834 has been marked as a duplicate of this bug. ***

(In reply to Muhammet Kara from comment #10)
> The bug is still valid on 5.2.0.4. Actually, TOC is not updated either on
> save or print.

Also the same on:

Version: 5.3.0.0.alpha0+
Build ID: f7dd958ad383c31fe380273d4a59e24fe6fe8caf
CPU Threads: 4; OS Version: Linux 4.6; UI Render: default; 
Locale: en-US (en_US.utf8);


I would like to fix this. Any code pointers?

(In reply to Cor Nouws from comment #13)
> Hi Muhammet,
> 
> (In reply to Muhammet Kara from comment #11)
> > 
> > I would like to fix this. Any code pointers?
> 
> kind! @jani, can you help Muhammet finding the right people (if he not
> already did on irc ;) )

Please remark that bug is still at "needDevEval" set so I am afraid code pointers as such is not enough. This is also not a easyHack and looking at the code it is a complicated bug.

But as suggested earlier, IRC is the best place to ask for pointers, and maybe understand why it still has needsDevEval set (which normally means it is something not very simple).

A good person to talk to on IRC is sweetshark.

have fun, looking forward to see your work.

(In reply to jan iversen from comment #14)

> Please remark that bug is still at "needDevEval" set so I am afraid code
> pointers as such is not enough. This is also not a easyHack and looking at
> the code it is a complicated bug.

Then maybe first back to discussion..

A possible way to circumvent that complicated part may be:
  - user starts print / pdf export
  - a dialog pops up
    "Do you want to update the TOC first"
    [ ]  do not show this question again
           [ YES ]   [  NO  ] 

Similar to Overwrite warning in Calc.

What do the UX people think of this?

I've used TOCs and never saw the point of having to manually refresh it, i would compare it to creating a chart and then manually telling it to refresh it after i changed some of the values associated to it.

So i'd suggest that the TOC be automatically refreshed without user prompt when a document is saved and before the launch of the print dialog.

(In reply to Yousuf Philips (jay) from comment #16)
> I've used TOCs and never saw the point of having to manually refresh it, 

From what I remember, Word did not do this automatically always.
So Google learns me there is the setting Options > Print > Update fields

What about adding some check boxes to the options of Writer?

There is already some checkboxes for Fields and Charts. What I understand from the LO Help is that these fields are automatically updated whenever their linked fields are updated. So the timing of updates seems a little different than what we discuss here.

Please check the attached screenshot to see what I mean. (I added the "Indexes and Tables" part.)

Created attachment 127669 [details]
New Check Boxes for "Indexes And Tables"

Unless we can identify a scenario that there would be a reason why a user wouldnt want this behaviour, i wouldnt suggest adding it to the already bloated options dialog. But if we have to add it to options dialog, then a single entry would be sufficient called 'Indexes and Tables' and have it in the 'Automatically Update' section.

(In reply to Yousuf Philips (jay) from comment #20)
> Unless we can identify a scenario that there would be a reason why a user
> wouldnt want this behaviour, i wouldnt suggest adding it to the already
> bloated options dialog. But if we have to add it to options dialog, then a
> single entry would be sufficient called 'Indexes and Tables' and have it in
> the 'Automatically Update' section.

I agree that the natural flow would be automatically updating those tables and indexes on save/print. I wonder if some users would want to disable this feature for performance reasons (maybe while working on very large documents?).

*** Bug 103107 has been marked as a duplicate of this bug. ***

De-assigning for now to avoid blocking others' work. I'll get back to this if not fixed after a while. Sorry for the noise.

(In reply to Muhammet Kara from comment #21)
> I agree that the natural flow would be automatically updating those tables
> and indexes on save/print. I wonder if some users would want to disable this
> feature for performance reasons (maybe while working on very large
> documents?).

Well printing the most accurate document would always be in the user's interest so i doubt there would be an issue there. For save, which a user can do multiple times in a session, if the updating of the ToC can always be done with minimal performance reduction to the saving process, then that would be idea. Else it should be done when the user saves during closing the document, which would only occur once.

@Heiko: What's your take?

@Muhammet: So you gonna take this back on as its been 6 months?

(In reply to Yousuf Philips (jay) from comment #24)
> @Heiko: What's your take?

Dont get the point why someone wants to print/save without updating the TOC. But Benjamin would also want to refresh it manually to ensure that things went right. Similar to a print preview. Putting that together an auto update checkbox being enabled by default sounds reasonable to me.

IMO there is no reason to NOT update the TOC on preview/print/save/create pdf/send/etc.

it's annoying to realize that the TOC was not updated prior printing, have to throw away paper.

it's embarrassing to hand out documents with wrong TOC, it does not look like professional work.

just my 2c

Thumbs up for an automaticaly updated TOC from me as well!

*** Bug 133048 has been marked as a duplicate of this bug. ***

In my case, I often create many Writer documents from a file. So when I change a header in the original file, I had to update its ToC and repeating tirelessly every ToC of all the documents. In some cases, I can trick the header by adding some fields so I just need to change it in the document properties. But the story of ToC quietly different, especially when I forget to update in a hurry situation.

Adding an option to make it updated automatically by default would not make it cluterred. We talk about an important part of a document here. I am not sure how this would affect performance but we have field and chart being update automatically by default. So, set is automatic update by default would might be no issue. Otherwise, we can set it to be updated after saving/printing.

*** Bug 135339 has been marked as a duplicate of this bug. ***

(In reply to Heiko Tietze from comment #32)
> Is this change really desperately needed? Importance is high...

Given the number of duplicates and people on CC it is a highly expected feature. So my take: keep it high. (It was questioned whether enhancement can have a high importance at all. It makes a lot of sense to me and I like the clear rules to set it.)

Skimming through the comments it looks like automatic update is welcome, even without an option to switch it off. Rizal is right, OTOH, the option wouldn't clutter too much and fits well into the current dialog.

Muhammet, as you were interested in this topic, could you please add a code pointer? Shouldn't be too difficult.

Don't see the need for deveval, removing the keyword.

I certainly (still) back the importance of this feature. :-)

(I think) It is quite natural to open the TOC's context menu for refreshing the TOC. So placing an option there seems a good alternative too. A tick-option could be added to the TOC's context menu.
Example: tables context menu, entry *template*, subentry *linebreak on end of page*

would be great if this gets implemented

Is this feature would be great for many users ? The answer often seems to be "yes".

To add documentation about this feature request:
- discussed 2004-2019, first FR I believe ! ;-) - Table of contents should be updated before printing (https://bz.apache.org/ooo/show_bug.cgi?id=25710)
- 2004-2015 - Auto updating Table of Content (TOC) (only when not modified manually (https://bz.apache.org/ooo/show_bug.cgi?id=24593)
- 2011-2018 - Add option for Chapter related Table of Contents update (https://bugs.documentfoundation.org/show_bug.cgi?id=34121)
- 2012-2023 - This bug

Pros
- Needed by many users
- Needed like every index, not only TOC (eg. figures, tables, etc.)
- As an option so it can be deactivate when not convenient for some long documents or in special cases

Cons
- Not present in 2023 (libreoffice 7.8.5.2, Debian GNU/Linux, testing/trixie)
- ???

As a workaround, I use:

The following macro:
```

And I assign it to the "Save" event (menu Tools/Macros/Manage macros/Basic then assign to the event "Save" (the name of the menus/buttons are translate from french, so it could not be the same in your version).
sub MajIndex
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:GoToStartOfDoc", "", 0, Array())
dispatcher.executeDispatch(document, ".uno:UpdateAllIndexes", "", 0, Array())

end sub
```

Hello together,

for me this is also a missing option in Writer.

I use following MACRO (find on https://forum.openoffice.org/en/forum/viewtopic.php?p=316538&sid=a0a4b71bb2908d87deb08b9b96e05e9f#p316538)

Wich works better for me, because Writer not always jump to first page...

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
sub TOC_Update

if ((ThisComponent.supportsService("com.sun.star.text.TextDocument")) OR (ThisComponent.supportsService("com.sun.star.text.WebDocument"))) Then
	oIndexes = ThisComponent.getDocumentIndexes()
	
	for i = 0 to oIndexes.getCount() - 1
	oIndexes (i).update
	REM If you want to get a message box when the index is updated
	REM remove the "REM" in front of the msgBox line below!!
	REM msgBox ("Index updated: " + oIndexes.getByIndex (i).getServiceName ())
	next i
end if

end sub
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Maybe it will be available in future, because many of my templates are also used by my colleagues at work.
And if the macro is not available for them, it doesn't work and only produces annoying error messages.

*** Bug 162861 has been marked as a duplicate of this bug. ***

This must be not a program option, nor a document-wide option, but a per-index option, similar to the existing "Protect against manual changes" (so it need an option in the file format). The auto-update may be enabled by default in new indexes, but it must be disabled in all existing indexes by default, so that existing documents would keep their behavior, unless users explicitly enable auto-update by editing existing indexes.

auto-update while editing the document and (auto) update before printing are two distinct features. Should they really be the same bug?

One might worry that, for larger and heavier documents, frequent auto-updating may slow down your work; while update-before-printing remains very useful.