FILESAVE DOCX/DOC: Distribution of bullet-ed items changes
Steps to Reproduce:
1. Open the attached file
2. Save as DOCX
3. File reload
Red highlighted item moves to first page from second
Same as ODT
User Profile Reset: No
Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: old;
Locale: nl-NL (nl_NL); Calc: group
Different look in
Maybe related to/caused by bug 134949
Created attachment 163266 [details]
yes, it moves to the first page, what's the problem ?
(In reply to Xisco Faulí from comment #2)
> yes, it moves to the first page, what's the problem ?
No clue, not sure how much comp-ability DOCX developers want to achieve; As it does change the page layout. Especially if you're working in LibreOffice & save it to DOCX, expecting it to be the same thing on re-opening
So if this can avoided, I personally would prefer it for interoperability reasons. But no clue what's reasonable here.
An developer opinion needed.. any worth having this.. or can it be closed not a bug
The real problem here is the footnotes - there is an extra footnote inserted in DOC/DOCX. Also, things are confused, because footnote 12 and 13 are shown on the next page.
This entry has two footnotes attached to it in the docx version.
Fahri Korutürk(1973-1980) (10 and 11).
This is definitely an export problem - extra footnote also seen in Word 2003.
(In reply to Justin L from comment #5)
> The real problem here is the footnotes - there is an extra footnote inserted
> in DOC/DOCX. Also, things are confused, because footnote 12 and 13 are shown
> on the next page.
> This entry has two footnotes attached to it in the docx version.
> Fahri Korutürk(1973-1980) (10 and 11).
> This is definitely an export problem - extra footnote also seen in Word 2003.
Dammit, didn't notice that! You're observational skills on document content is better than mine :-).
Extra footnote also found in
but not in
[Automated Action] NeedInfo-To-Unconfirmed
linux bibisect44max 4.4 commit 54d52f6062dffaa930f008c9e1655132dd395c83
Author: Umesh Kadam <firstname.lastname@example.org>
CommitDate: Thu May 22 02:31:53 2014 -0500
tdf#78333 : SdtContent and a Shape overlapping causes corruption
- Normally if there is a case where text/shape is overlapped with (another)
shape then LO used to write the text and the AlternateContent in the same run.
- This is supported in MSO and there is no visual difference.
- But in case if the SdtContent(with text) is overlapped with the Shape then LO
processes sdtContent as a text and ends up putting the alternateContent and the text in a single run. Ultimately it includes the entire run in a SdtContent,
which is incorrect.
- The fix checks for the aforementioned scenario and puts them in a different run
and also restricts the sdtContent being written in an invalid AlternateContent.
Link the commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=80fd9fb7209cfd5c0622ee99d59e42e6db32f021
Here are some follow-up commits to the regressive one that might be useful:
Author: Ravindra Vidhate on Wed Jun 11 16:38:17 2014 +0530
fdo#79915:Text Data Lost after exporting through LO
Author: Rohit Deshmukh on Fri Jul 11 15:18:17 2014 +0530
fd0#80997: Fix for text missing which is behind textbox in RT.
Author: Miklos Vajna on Tue Sep 23 17:48:40 2014 +0200
DOCX export: fix duplicated OLE objects
Created attachment 164001 [details]
tdf134951_patch.diff: working patch with debugging
There probably is something more fundamentally wrong happening here. Like, why would a new paragraph be started without a new character set, and when it is finished, why wouldn't they be popped, and then just continue with the existing pair on the stack?
So I'm not planning to submit this as a patch. However, I think it would be fine to do if this bug really needs fixing.
Removed references to DOC since other bugs suggest that DOC format should completely avoid this bPostponeWritingText craziness.
(In reply to Justin L from comment #13)
> Removed references to DOC since other bugs suggest that DOC format should
> completely avoid this bPostponeWritingText craziness.
In bug 134948, bPostponeWritingText was isolated to only affect DOCX. Unfortunately, unit tests still fail if we eliminate it altogether.
Justin Luth committed a patch related to this issue.
It has been pushed to "master":
tdf#134951 docxexport: stop duplicating stuff in postponed text
It will be available in 7.2.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
So, I'm going to mark this as fixed based on the modified subject, and comment 5.
The part about all 12 footnotes not showing up on the first page is still there, but even on the original ODT, if I move the picture anchor up just one paragraph then the same thing happens (for no apparent reason). And moving it down one again doesn't "fix" it either - it needs to bump down all the way to footnote 12's paragraph before the layout changes again.
This layout issue probably is not worth reporting as a bug until something more concrete can be identified as causing the problem.