Created attachment 89697 [details]
ODT File with Two Styles
I am relatively sure that this has to do with the fact that I use a different style for my first page (to avoid headers/footers).
Steps to Reproduce:
Save as .doc
Look at page 2 and 3, you can see that a page break is thrown in after the first line of page 2 (which isn't in the original odt at all).
Additionally you can see that styles are changed. In the original odt the first page is "first page" everything else is "default style" with the .doc the same document first two pages are "default style" and then all other pages become this "convert 1" style (which isn't used at all in the odt).
I did the same procedure on the last stable release of 3.6 and we get similar problems with styles but no page break -> the styles issue is that all pages become "default style" which is actually preferred over the current setup which completely screws up all formatting.
While this document is going up public -> please note that this is a final submission of a legal paper so basically it's quasi copyrighted under my name ;)
Major - significant loss of data/formatting
High - default, might be even highest as it's a regression but I'll let someone else decide this:)
Confirming. Save as doc, reopen with LO and see that page 2 has a page break which does not exist in original document.
Setting to NEW.
Is this the same problem reported in bug 41650 ? This report is much clearer, whereas the earlier one started life as a general "text loses formatting" report but has now been somewhat clarified to deal with this particular issue. It may be cleaner in this instance to close the earlier bug. Just wanted to point out the similarity.
I can confirmed this bug as well.
I see it as a partial duplicate but not completely. Unfortunately on that other one - it's many bugs in one and probably why it hasn't been touched by a developer. One paragraph I thinks states 4-5 separate problems, one of which is the one listed in this bug
(In reply to comment #3)
> Is this the same problem reported in bug 41650 ?
It is one of the problems in that issue indeed.
I split them up, see
Let's wait what the devs (cc in #16) will say.
Pretty sure that this is a good bibisect. Lowering to normal as this can prevent high quality work but is not data loss
f89e78929fb81d824ac5ad2b3063a7f73ed47c9a is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Wed Dec 7 12:43:15 2011 +0100
Author: Andras Timar <firstname.lastname@example.org>
AuthorDate: Fri Sep 16 16:20:09 2011 +0200
Commit: Andras Timar <email@example.com>
CommitDate: Sat Sep 17 10:18:18 2011 +0200
add KeyID option to Language dropdown box
:100644 100644 ab0595641102029f7ba0a38bda6553bf144f6d62 ad52957ec21e00054d9a6275215d01ec311b0533 M autogen.log
:100644 100644 f1776e218e615ee16234fda621551b17913e87b7 db8269702742f972a3dbd7e739430bd0b47a117c M ccache.log
:100644 100644 e4bfdb45b33fb0ec0cafb2b41f0b35a389bf26bd 1b3a0a68d8f65b094b0a8f4b16397379b6ef08a7 M commitmsg
:100644 100644 b76274ecc9f917a09f00a032b12352db356e377b 112dcd49b4b53a8e513e7771fbbf5cfa8cffd620 M dev-install.log
:100644 100644 d8894603ec34f90e21ef518aac5c5b0fa425b34e d8af8c11c7af0f1089bd75919e66568a9be01f1a M make.log
:040000 040000 015bad708b8e165da96667dcf17f583220b4ae10 4d782b721c121f08814ffcb9abe4f29b70c30440 M opt
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect bad 369369915d3582924b3d01c9b01167268ed38f3b
# bad: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c
git bisect bad 351622aec2dff3cc3bbbb020ad0097c4322d2a21
# bad: [035c276ec5a8da669e6043a3db6b0701dd3c2ade] source-hash-dc8249af103741415a074d9bbf8b1211f24a7c3f
git bisect bad 035c276ec5a8da669e6043a3db6b0701dd3c2ade
# bad: [4225403645019b6af53db0bf9ba9bbd063e9aa93] source-hash-cf16ef6c250a2755155a02f24bad861b35a1f92b
git bisect bad 4225403645019b6af53db0bf9ba9bbd063e9aa93
# good: [07e8171f32b03a1146ef80d086c2dd61f3def5aa] source-hash-886762160996dfa3fee07cf135e53dfe952ed298
git bisect good 07e8171f32b03a1146ef80d086c2dd61f3def5aa
# bad: [a0486a18ac4ea6508f02804cf2624c46607674af] source-hash-a0a1c3f4fb730ed3614593c3d8ddb50c23204c29
git bisect bad a0486a18ac4ea6508f02804cf2624c46607674af
# bad: [f89e78929fb81d824ac5ad2b3063a7f73ed47c9a] source-hash-a705aec5117fe9123236ebdeb0d6f271b83f8af4
git bisect bad f89e78929fb81d824ac5ad2b3063a7f73ed47c9a
# good: [e65850d4d23beb93ded3cab9e5945dd39c530738] source-hash-a44dda4b7d71f8d2b4e0cca79d732eab89588c3a
git bisect good e65850d4d23beb93ded3cab9e5945dd39c530738
# first bad commit: [f89e78929fb81d824ac5ad2b3063a7f73ed47c9a] source-hash-a705aec5117fe9123236ebdeb0d6f271b83f8af4
cannot reproduce a page break with 220.127.116.11, 18.104.22.168 or 22.214.171.124
... but it does happen in current libreoffice-4-2
broken since 126.96.36.199
Author: Pierre-Eric Pelloux-Prayer <firstname.lastname@example.org>
AuthorDate: Thu Jan 10 18:45:42 2013 +0100
docx export: invalid sectPr added at the beginning of the doc
(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".
Migrating Whiteboard tags to Keywords: (bibisected)
(In reply to Joel Madero from comment #0)
> Steps to Reproduce:
> Open Document
> Save as .doc
> Look at page 2 and 3, you can see that a page break is thrown in after the
> first line of page 2 (which isn't in the original odt at all).
Looking at this in daily from 20160902, the problem is resolved. (I expect as a result of the good works from Justin Lith). I set it as WorksForMe - please reopen if I'm wrong.
(NB something else with the page wrapping is not perfect - on page 18 the doc files has three lines more from the previous page.