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.
Created attachment 95853 [details] test result docx file Attached the docx file saved from the above odt file.
Created attachment 95854 [details] screenshots shows the endnote difference My OS: Fedora 20 LibreOffice 4.2.3.1 Build ID: 3d4fc3d9dbf8f4c0aeb61498a81f91c5b7922f13
reproducible with LO 4.2.1.1 (Win 8.1)
# 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: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d3ff876f3c7f441fd72a037ed31fb973f223ca6d..79850f25987d12c8ee91dfd0f699a562f341bf67 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.
Note that the fix for fdo#68787 was backported to 4.0, so t
(please ignore comment 5)
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
(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 4.2.3.1.
(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
(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".
This is not Linux but also Windows issue.
Migrating Whiteboard tags to Keywords: (bibisected, filter:docx) [NinjaEdit]
Do not reproduce with Version: 5.1.0.2 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.