Created attachment 138328 [details]
Update ToC to see duplication.
Updating the ToC index object, either calling update() through UNO or right-clicking on the ToC in the UI causes the top-level entries to duplicate.
See attached document and screen shot, see also https://forum.openoffice.org/en/forum/viewtopic.php?t=91448#p433507
Created attachment 138329 [details]
Left before, right after ToC update.
Also happens on 188.8.131.52 and 6.0.0 beta, both Mac and Linux.
Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default;
Locale: en-US (en_US.UTF-8); Calc: single
Build ID: 1d8cb97fea57b81a1ab151b88c2180e646bd401b
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-07_01:51:53
Locale: en-US (en_US.UTF-8); Calc: threaded
Not only you'll get a double index, but you can't undo it.
Showing duplicates on file open
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Showing duplicates after updating the TOC in
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec
(Just reporting some experiments.)
The example file is provided as .docx. The issue persists if the document is first saved as .odt and then reloaded. Creating the TOC anew in the reloaded document works without a problem and the new TOC does not show the issue.
With LibO V184.108.40.206 x64 on Win 10.
Same with V220.127.116.11beta1 x64 on Win 10.
AOO 4.1.3 does not show the issue.
Happens only if ToC created both from Outline and Additional heading styles.
So, looks like user error to me and not a bug.
Turn of either of them and you'll get what you want.
These are customer documents. Could somebody please elaborate on what went wrong and how to go about the issue? I don't quite follow @Timur's explanation.
ToC right-click, Edit.
Turn off Outline OR Additional styles, depending what you want.
What you ask is for ask.libreoffice.org and not for bug report.
(In reply to Wolfgang Jäger from comment #6)
> AOO 4.1.3 does not show the issue.
Interesting, that must've been changed because this behavior is from OO.
We might say this is a bug and this should not duplicate if the same, like AOO.
But I'm not in favor of that approach.
I'd like to have it displayed exactly as checked.
Those who set it up should know what they're doing.
Note: saving this docx shows Bug 112539.
Considering that the document is a DOCX Word native format I take it that Word is the reference and defines the baseline behavior. When I update the ToC in Word, entries are _not_ duplicated. It seems that AOO does not have this problem either.
Clearly there is a regression between Word and LO.
So instead of expecting LO users to tweak the document's settings after it's loaded (see this comment: https://bugs.documentfoundation.org/show_bug.cgi?id=114363#c9), I think LO should handle this like the baseline reference: without duplicating entries and without expecting the user to tweak anything.
Please don't set wrong status yourself. Reopened is where fix doesn't work.
This one is not confirmed, not only a behavior but a possible fix. You may wait for a dev or UX to confirm, but cannot do it yourself.
(In reply to Timur from comment #7)
> Happens only if ToC created both from Outline and Additional heading styles.
> So, looks like user error to me and not a bug.
> Turn of either of them and you'll get what you want.
I disagree. If I create a document and create ToC both from Outline and form Heading Style there is no dubication
I can also (In reply to MM from comment #3)
> Confirmed with
> Version: 18.104.22.168
> Version: 22.214.171.124.alpha0+
> Not only you'll get a double index, but you can't undo it.
I can also confirm it but only wth that specific document from the original bug report => Set to NEW
Is there any progress update on this problem?
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still reproducible in
Version: 126.96.36.199.alpha0+ (x64)
Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10
Locale: en-US (de_DE); UI-Language: en-US
Still reproducible in LibreOffice 188.8.131.52 7bcb35dc3024a62dea0caee87020152d1ee96e71.
Created attachment 156074 [details]
DOCX updated in MSO
I opened DOCX in MSO 2013 in Windows and after an update to ToC there was an error.
I added another ToC before that one.
Here is updated DOCX.
When I open this new DOCX in LO, I get proper first new ToC without doubled content. Update ToC doesn't spoil it (except ToC title itself).
I see an error for previous ToC from original DOCX. It can be updated in LO and then it doubles chapter titles.
This is NotOutBug.
So… your solution to this is have people open a DOCX file in Words, resave it, so they can open it in LO?
I have plenty of Word documents that _do_ show duplicate ToC when I open them in LO and they are just fine in Word. And as such I argue that this is indeed a LO bug.
(In reply to Timur from comment #20)
> I opened DOCX in MSO 2013 in Windows and after an update to ToC there was an
What kind of error did you get? I'm not seeing any errors when updating the ToC in Word 2013.
(In reply to Jens Troeger from comment #21)
> So… your solution to this is have people open a DOCX file in Words, resave
> it, so they can open it in LO?
> I have plenty of Word documents that _do_ show duplicate ToC when I open
> them in LO and they are just fine in Word. And as such I argue that this is
> indeed a LO bug.
If there's indeed an error when updating the originally attached sample's ToC in Word (I haven't encountered one myself), having a clean sample would be helpful.
> If there's indeed an error when updating the originally attached sample's ToC in Word (I haven't encountered one myself), having a clean sample would be helpful.
Download the original attachment, open it in LO, right-click on the generated ToC and update it. All entries will duplicate. That is the bug, as these entries should _not_ duplicate.
Created attachment 156085 [details]
DOCX when updated in MSO - screenshot
(In reply to Aron Budea from comment #22)
> (In reply to Timur from comment #20)
> > I opened DOCX in MSO 2013 in Windows and after an update to ToC there was an
> > error.
> What kind of error did you get? I'm not seeing any errors when updating the
> ToC in Word 2013.
I updated the entire ToC, not just numbers and got some message, but ToC looks wrong, same as when opened in LO. Attached.
(In reply to Jens Troeger from comment #23)
> Download the original attachment, open it in LO, ...
Sorry, no. File must be a proper one. If it makes trouble in MSO, it cannot be a reference for LO. And it happens in other bugs also, that it's different in different MSO versions or that it's wrong there.
I don't know how the original was created but there's a problem.
Please see .DOCX I uploaded with both ToC and test those in LO.
Note: I wrote "MSO 2013 in Windows" and I noticed that Jens' is "Microsoft Macintosh Word 15". I don't have more recent MSO, but we cannot chase MS differences.
(In reply to Timur from comment #24)
> I updated the entire ToC, not just numbers and got some message, but ToC
> looks wrong, same as when opened in LO. Attached.
I did the same in the original sample, in Word 2013, and the ToC stays as it is.
I also get the ToC back in your sample, if I update the second ToC that says "No table of contents entries found". Probably some Word strangeness is at work (locale-based, perhaps?), but I'd say the original sample is valid. Let's reopen the bug report.
> Sorry, no. File must be a proper one. If it makes trouble in MSO, it cannot be a reference for LO. […] I don't know how the original was created but there's a problem.
It _is_ a proper DOCX file straight out of Word two years ago when I opened the bug.
Today I tried it again using Word 16.16.15, and it works just fine and as expected. It does not work with LO 184.108.40.206 (i.e. ToC duplicates when I update it).
Version: 220.127.116.11 / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
same case, same format.
Created attachment 174025 [details]
The original example file in Word and Writer
The document and its TOC are formatted in a way that updating the TOC in Word results in an empty TOC. The incorrect import of such settings results in too many entries.
As highlighted in this image:
- The setting Outline (Vázlatszintek on the left) is turned OFF in Word, but imported as turned ON in Writer.
- In the TOC-Settings dialog of Word only Heading 2 and Heading 3 are enabled as additional styles to be included into the TOC. (the document has no paragraph formatted with these, so updating in Word will result in an empty TOC)
In Writer the Assign Styles dialog shows Heading 1 is enabled on first level (should be disabled) and Heading 2 and Heading 3 are disabled (should be enabled and assigned to 2nd and 3rd TOC levels).
Manually changing these to match Word settings and updating the TOC results in an empty TOC, just like in Word.
Version: 18.104.22.168.alpha0+ (x64) / LibreOffice Community
Build ID: 7c38362dbe1922c9825dffb463072030948d406b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: en-US (hu_HU); UI: en-US