Bug 112539 - Index TOC 'eats' next paragraph (may also be a page crossing) after saving as docx
Summary: Index TOC 'eats' next paragraph (may also be a page crossing) after saving as...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 105969 (view as bug list)
Depends on:
Blocks: DOCX-TableofContents DOCX-Bullet-Number-Outline-Lists
  Show dependency treegraph
Reported: 2017-09-21 07:40 UTC by Cor Nouws
Modified: 2019-04-08 15:34 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2017-09-21 07:40:17 UTC
1. Open attachment 136352 [details] from bug 41650
  Notice that 2nd page has TOC with one paragraph after
2. Save as docx, close and reopen
  > Index now includes next paragraph including page crossing
this is wrong

Updating index makes it shrink again, but extra paragraph still is in the index, and the page crossing (different page style) got lost.

 a. first add extra paragraph after index, before saving as docx & reopen.
 > page crossing preserved, but extra paragraph included in index
 b. test with paragraphs and without page crossing, save as docx & reopen.
 > extra paragraph still included in index
Comment 1 Cor Nouws 2017-09-21 07:40:58 UTC
*** Bug 105969 has been marked as a duplicate of this bug. ***
Comment 2 Cor Nouws 2017-09-21 07:45:59 UTC
OK in 5362, Wrong in 5421 > regression

Also tested in Version:
Build ID: afeff9102c2935139de4efd40fd2286dce396706
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-17_23:32:41
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 3 Xisco Faulí 2017-09-21 08:36:35 UTC
Regression introduced by:

author	Michael Stahl <mstahl@redhat.com>	2017-03-02 21:55:27 (GMT)
committer	Michael Stahl <mstahl@redhat.com>	2017-03-02 22:26:38 (GMT)
commit 06f9ad262742ea939bf23e82530b7166ca4ce456 (patch)
tree 9e2186a67301b7d9ecfdae661d07568075b96b49
parent 100da4fadbab795bf470a2e46790d36a7c46d944 (diff)
sw: Fix STL assert on DOCX export of ooo29679-42.odt
The problem was that the StartField_Impl() was called again and again on
the same field (actually 0-length ToXmark with dummy char), or in other
words, EndField_Impl() wasn't called and it wasn't removed from

So tweak the south-pointing chariot DocxAttributeOutput::EndRun() again
in the hope it will go another km or two before it starts pointing east.

This doesn't actually produce the elements in the ideal order in some
cases, but given that this code has clearly passed the complexity event
horizon that is too much to ask for.

Bisected with bibisect-linux-64-5.4

Adding Cc: to Michael Stahl
Comment 4 Michael Stahl (allotropia) 2017-09-21 10:30:42 UTC
eh i'm not inclined to touch the south-pointing chariot again ...
Comment 5 Cor Nouws 2017-09-21 12:58:02 UTC
@xisco - thanks for fast bibisecting
@michael ;)  ..
Comment 6 Buovjaga 2019-04-05 12:13:51 UTC
This works OK now!

Arch Linux 64-bit
Build ID: 558956dc811a1f0f07411e348f7081a467bbc3b5
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 4 April 2019
Comment 7 Gabor Kelemen (allotropia) 2019-04-08 15:32:12 UTC
A quick bibisect shows that this commit has solved it:


Thanks Serge!