https://bugs.documentfoundation.org/show_bug.cgi?id=44448
--- Comment #44 from Eyal Rozenberg <[email protected]> --- Some replies to various comments... (In reply to Eyal Rozenberg from comment #40) > auto-update while editing the document and (auto) update before printing are > two distinct features. Should they really be the same bug? No comment so far suggested otherwise. But there is yet another distinction! Updating a TOC can mean: 1. Changing page numbers 2. Changing structure/content, i.e. adding, removing, and changing level of ToC'ed headings 3. Changing the styling - dropping DF in favor of the Content1, Content2 etc. styles At the moment, LO can only update everything at once. And considering that we can have manually-editable ToCs - the user's interest in auto-updating on print is not clear: Do they want us to overwrite all of the changes they've made? Do they want us to just update the page numbers (see bug 169210)? Update the structure/content but not any formatting that they've made? ... or we could just say that auto-update is only intended for non-manually-editable ToCs? (In reply to Yousuf Philips (jay) (retired) 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. Scenarios: 1. A (full) update of a ToC can add items to it which the user many not have noticed would be visible in the ToC (e.g. in styles that it covers but the user hasn't noticed/forgotten); the user would not want to see these items in the printed ToC. 2. A (full) update of a ToC can make it significantly longer or shorter, and if the user has not carefully managed page breaks, object positioning and such - can wreak havoc on the layout of the document. The user would not want to messed-up document printed. 3. The user made manual changes to the ToC which the user would not want to lose. (In reply to Rizal Muttaqin from comment #43) > How about enabling ToC auto-update by default if only the document has page > break after ToC? That would mitigate issue (2.) above, but not (1.) and (3.). And even with (2.) - that's still not good enough, because maybe the user relied on the oddness/evenness of pages in some way, e.g. with a choice of placing certain content in left-of-gutter or right-of-gutter pages. > Or may be the question could be broader: How if LibO Writer enables page > break (at least with same page style with ToC's page style) by default? This > question lead to another bug report Please file it then. (In reply to Yousuf Philips (jay) (retired) from comment #24) > Well printing the most accurate document would always be in the user's > interest so i doubt there would be an issue there. I would say, that the clear user interest is to be warned about the ToC being out-of-sync. > 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. I dislike the notion of the saved file being different to what the user was looking at when they save. Unless... hmm, that gives me an idea: Just filed bug 169211. Anyway, bottom line for me: -> Let's not auto-update, but rather warn, on printing, if the ToC is not-manually-editable and is out of sync. It's a more modest benefit for those who want full automation, but avoids the three problematic scenarios mentioned above. And let's forget about any such action on save. -- You are receiving this mail because: You are the assignee for the bug.
