Bug 76204 - Endnotes with line/paragraph breaks corrupted when saving ODT as DOCX
Summary: Endnotes with line/paragraph breaks corrupted when saving ODT as DOCX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) Master
Hardware: All All
: medium major
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Reported: 2014-03-15 12:47 UTC by Kevin Suo
Modified: 2018-03-22 13:53 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

the test case odt file, with some endnotes (9.72 KB, application/vnd.oasis.opendocument.text)
2014-03-15 12:47 UTC, Kevin Suo
test result docx file (4.57 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-03-15 12:51 UTC, Kevin Suo
screenshots shows the endnote difference (30.10 KB, application/vnd.oasis.opendocument.text)
2014-03-15 13:03 UTC, Kevin Suo

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2014-03-15 12:47:32 UTC
Created attachment 95852 [details]
the test case odt file, with some endnotes

Problem description: 
When saving the attached odt file as docx (ms office 2007/2010/2013 xml), the line breaks and paragraph breaks in the endnotes are corrupted.

Steps to reproduce:
1. Save the attached odt file as docx.
2. Open the saved docx file in LO

Current behavior:
the line breaks and paragraph breaks in the endnotes are corrupted.

Expected behavior:
The endnotes should be the same as in the odt file.
Comment 1 Kevin Suo 2014-03-15 12:51:21 UTC
Created attachment 95853 [details]
test result docx file

Attached the docx file saved from the above odt file.
Comment 2 Kevin Suo 2014-03-15 13:03:21 UTC
Created attachment 95854 [details]
screenshots shows the endnote difference

My OS: Fedora 20
LibreOffice Build ID: 3d4fc3d9dbf8f4c0aeb61498a81f91c5b7922f13
Comment 3 A (Andy) 2014-03-15 13:40:17 UTC
reproducible with LO (Win 8.1)
Comment 4 Björn Michaelsen 2014-03-16 11:30:38 UTC
# bad: [25428b1e953636f74986622c5df614f04c150ed1] source-hash-cb4e009c4539c535108021934e545194b35cad9d
# good: [f0f6c65eb764f0303f59c58d320e9b0d5a894377] source-hash-4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2e
git bisect start 'latest' 'oldest'
# good: [a72833796a7e527d9efc9ca6d8fe9b579e469105] source-hash-1472b5f87314fe660ef1a7b254e51272669f12f6
git bisect good a72833796a7e527d9efc9ca6d8fe9b579e469105
# good: [b21386bf459ae47bd6e461ea94cea6a06729a1ff] source-hash-570fe620e9d573cfc9fc260e6518563c6a6c1a3c
git bisect good b21386bf459ae47bd6e461ea94cea6a06729a1ff
# good: [091d742e82f2b4608690c697d14f846ffc9164c7] source-hash-349c91c8ec6afc1f5c8499529d559af34d115a76
git bisect good 091d742e82f2b4608690c697d14f846ffc9164c7
# good: [14568733447b0c4b9218b7258182594ee4e9ad6e] source-hash-d3ff876f3c7f441fd72a037ed31fb973f223ca6d
git bisect good 14568733447b0c4b9218b7258182594ee4e9ad6e
# bad: [f5ac2f724a49dc002f9fc6be7afe17f741cc7f8f] source-hash-dca003a486acb63ea7ba6aaba94f6c9d3715b004
git bisect bad f5ac2f724a49dc002f9fc6be7afe17f741cc7f8f
# bad: [42c3b422339a4d15dd66dcdb7e7662b348f36307] source-hash-d261ddf3c8e76b44b07ea8be69234a123d2f4271
git bisect bad 42c3b422339a4d15dd66dcdb7e7662b348f36307
# bad: [2ffc54d4f5fb1f292e5dd2723834af4f5258fa6c] source-hash-40d7608667014d54562658daec4650d068621e90
git bisect bad 2ffc54d4f5fb1f292e5dd2723834af4f5258fa6c
# bad: [e304eab55371f66c773bfb7e4f6a8c321db175d6] source-hash-79850f25987d12c8ee91dfd0f699a562f341bf67
git bisect bad e304eab55371f66c773bfb7e4f6a8c321db175d6
# first bad commit: [e304eab55371f66c773bfb7e4f6a8c321db175d6] source-hash-79850f25987d12c8ee91dfd0f699a562f341bf67

Thus the offending commit is in:

of those:

commit 3f2774c771fc54757364ed50fab9b4753d067371
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Wed Sep 4 17:19:47 2013 +0200

    fdo#68787 DOCX export: handle zero width footnote separator
    Change-Id: Ieb1d8d1f8609558b4af06630b603a51da3e665

looks suspicous.
Comment 5 Björn Michaelsen 2014-03-16 11:37:04 UTC Comment hidden (obsolete)
Comment 6 Björn Michaelsen 2014-03-16 11:37:54 UTC Comment hidden (obsolete)
Comment 7 Björn Michaelsen 2014-03-21 09:19:04 UTC
Possibly related to rhbz#1065629, and maybe even fixed on 4.2 by:

Comment 8 Kevin Suo 2014-03-21 09:24:14 UTC
(In reply to comment #7)
> Possibly related to rhbz#1065629, and maybe even fixed on 4.2 by:
>  https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;
> h=153993292cc9f11fed8fcba8de45b0c46d5e0ef2

I don't think it is fixed in 4.2. See the attachment "screenshots shows the endnote difference", which was reproduced from
Comment 9 Michael Stahl (allotropia) 2014-07-02 22:00:04 UTC
(please ignore comment #7 too, since this bug is about DOCX while the cited commit is about RTF import...)

the commit in comment #4 does not look responsible either.

*Bjoern gets 0 points for guessing*

it looks like the problem is on the import side, since the files
produced by the 2 bibisect builds do not differ...

regression from:

commit 330b860205c7ba69dd6603f65324d0f89ad9cd5f
Author:     Miklos Vajna <vmiklos@collabora.co.uk>
AuthorDate: Wed Sep 4 16:08:49 2013 +0200

    fdo#68787 DOCX import: handle when w:separator is missing for footnotes
Comment 10 Björn Michaelsen 2014-10-16 14:59:15 UTC
(This is an automated message.)

It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)

Thus setting keyword "bisected".
Comment 11 Timur 2015-04-08 13:01:31 UTC
This is not Linux but also Windows issue.
Comment 12 Robinson Tryon (qubit) 2015-12-13 12:15:49 UTC Comment hidden (obsolete)
Comment 13 Kevin Suo 2016-01-30 05:40:07 UTC
Do not reproduce with
Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
Locale: zh-CN (zh_CN.UTF-8)

May already been fixed somewhere. Mark as WORKSFORME.