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".
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.