Created attachment 137776 [details] The sample files that allow easy observation of the bug I discovered this bug when using Calibre to convert LO-created .docx files to epub and .mobi formats for ebooks. (I need to use the .docx format because the support for it in Calibre is better than for .odt files.) If you open the example file provided (ShadowHunt-KDP-PageBreakProbs.odt) and save as .docx format, LO will insert three extra page breaks - one visible, two invisible. The visible spurious page break occurs immediately after the phrase "make her new home perfect." The two invisible spurious page breaks occur immediately the phrase "to pans and pots." and after the phrase "had also been the worst night." Each of these phrases happen to end paragraphs at the bottom of a page - but without any manual page break. After saving as .docx however, a manual page break has been inserted at that point in the .docx. The invisible page breaks can be revealed by converting into another format where re-pagination can occur, or if the bulk of the document is converted to a smaller font size. The file ShadowHunt-KDP-PageBreakProbsOdt.odt is the sample document. The file ShadowHunt-KDP-PageBreakProbsOdt.docx is that file saved as .docx. The file ShadowHunt-KDP-PageBreakProbs-ManlFix1.docx is the .docx file with the visible spurious page break deleted by positioning the cursor at the end of the paragraph and hitting Delete and then Enter to break it back into the correct paragraphs. The file ShadowHunt-KDP-PageBreakProbs-ManlFix2.docx is that file with the two invisible page breaks fixed the same way. I have rated this as a major problem because it means if LO is used for ebook production, it introduces a significant quality problem to the ebooks produced. In addition, it means any edits to the .odt file mean all the manual corrections to the .docx file need to be done again. This is exacerbated by the inability to search for manual page breaks in LO. This further means that while this bug exists, the.odt file is therefore unsuitable for use for writing books.
They are not added, they already exist in the .odt. The visible thing after "make her new home perfect." is a non-breaking space. Just remove it. Looking inside the content.xml we see the invisible things are soft page breaks: to pans and pots.</text:p><text:p text:style-name="Text_20_body"><text:soft-page-break/> had also been the worst night.</text:p><text:p text:style-name="P6"><text:soft-page-break/> I did not find a way to remove the soft page breaks in the LibreOffice GUI. So you would have to unzip the .odt and edit the content.xml to remove the <text:soft-page-break/> elements manually. Then zip everything back again and rename the file type to .odt. I found a mention of soft page breaks related to Page styles using Next style, but when I changed it in your document it did not help: https://help.libreoffice.org/Writer/Changing_Page_Orientation_Landscape_or_Portrait#One_Page_Long_Styles Closing as NOTABUG.
Sorry, I dispute this. Since when is a non breaking space a page break? I never inserted any of these page breaks, and the idea of literally inserting a "soft" page break just because the page style changes seems ludicrous to me. The reason for changing page styles is that typically in a book, pages that start a new chapter are formatted differently (e.g., no header and /or footer). And if this ludicrous behaviour was correct, then LO would be causing this unwanted behaviour after every new-chapter page, not just on those where the end of a paragraph happens to fall at the end of the page. Note that I tried the experiment, before submitting the bug, of deleting the end-of-line after "pans and pots." and then hitting Enter, and re-saving as a .docx: LO re-introduced the invisible page break. I certainly didn't insert and soft page breaks! Doing that would be most unwise, since any editing of the document would change the layout of many pages and ruin the formatting. I also did not suffer this problem until recently. So it seems to be new behaviour with LO 5.4.2 or thereabouts. It was not a problem with my previous two books over the last two years, nor this third book until I tried to update it this month. In my opinion this IS a bug, and a serious one. Please re-check. If it is a new feature, and it is the way LO will be from now on, then I'll know to finally give up on LO and switch over to an alternative, like WPS, or run MS Office running under Wine. Or try the Apache fork. Please investigate further.
I tested on 3.6 and the problems do not occur, so adding bibisect request. Arch Linux 64-bit Version: 6.0.0.0.alpha1+ Build ID: 121303615054568c204def97872343d2014af4a0 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 16th 2017 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Thank you!
Repro with Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 No repro in Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89
@Luke You might be interested in this: https://vmiklos.hu/blog/basic-epub3-export.html
Still repro, will bibisect later. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: ea39c41fdf63191579d25f327db81db14862251c CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on July 4th 2018
Bisected on Linux with 41max to commit 1aa664e781c50a322170070e7668cce173a23b4f Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:19:41 2015 +0800 source-hash-ee9f23bb94b4c2c8c4db6466ecca272a092e9492 commit ee9f23bb94b4c2c8c4db6466ecca272a092e9492 Author: Pierre-Eric Pelloux-Prayer <pierre-eric@lanedo.com> AuthorDate: Thu Jan 10 18:45:42 2013 +0100 Commit: Noel Power <noel.power@suse.com> CommitDate: Mon Jan 14 15:35:13 2013 +0000 docx export: invalid sectPr added at the beginning of the doc This reverts commit 60fa5057039d2413d56813df4d45e5cfdfbb40ac, which was a revert of 723f772d (fix for ooo#106749) with an alternative fix to avoid a regression (fdo#56513). This commit contain a fix for the sectPr issue, and does not regress on the 2 previously fixed issue. Change-Id: Ibc551b38d25554c59b7c4ac5a447a0d60323f53f Reviewed-on: https://gerrit.libreoffice.org/1647 Reviewed-by: Noel Power <noel.power@suse.com> Tested-by: Noel Power <noel.power@suse.com>
Seems to be a dupe of bug 93366 *** This bug has been marked as a duplicate of bug 93366 ***
@Justin Luth, I thought you could be interested in this issue. It was caused by ee9f23bb94b4c2c8c4db6466ecca272a092e9492, which was the same as for bug 93366, which was fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=7e92a996d1588bdf2ff1e2df10220a0f57686cfb
dangerous stuff, as evidenced by the fact that the offending patch reverted a couple of other patches, and affects both doc and docx. As a reminder to myself when I eventually look at this - the referenced doc fixes have no relevance for this docx bug, so start debugging from scratch.
Lots of problems here. 1.) For some reason, title-page (First/Follow) isn't working. I assume that is because the inside/outside margins are too different between the two page styles. It automatically looks a lot better when they are the same. (I don't think that docx has the idea of a First/Follow style, just a Title page (which has all the same margins by definition). 2.) The footer is missing from even pages in docx (but not in .doc). Probably because header is different even/odd, but footer is not?
(In reply to Justin L from comment #12) > 1.) For some reason, title-page (Title/Follow) isn't working. I assume that > is because the inside/outside margins are too different Correct. This prevents IsPlausableSingleWordSection(). > (I don't think that docx has the idea of a Title/Follow page styles Kinda correct - I guess a continuous section serves that role, but continuous sections are an anathema to LO. So, we have to try to emulate title/follow when exporting to DOCX format, and frequently that can be done if the follow style doesn't already have a different "first page". In that case, if IsPlausableSingleWordSection, then we consolidate the two page styles into one, marking the initial headers/footers as "different first page". ***Ideally, if you plan to export to MS formats, try to use "different first page header/footers) instead of title/follow page styles.*** > 2.) The footer is missing from even pages in docx (but not in .doc). > Probably because header is different even/odd, but footer is not? Correct. proposed fix at https://gerrit.libreoffice.org/65699 and gerrit.libreoffice.org/65700 One reason the page breaks were noticeable after the Chapter page was that the text wasn't fitting all on one page. Undefined even headers/footers being inherited from previous page styles took up some extra space. That was fixed in LO 6.1 by Tamas' commit 6aa1df5a627697e6adaee70adcef2c5b50cfcbf7.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/7815b4d2a2c89261ad6424c7fe3ce0c453e4d02c%5E%21 tdf#113849 ooxmlexport: even headers/footers for both or none. It will be available in 6.3.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/303e03115e59c8e8c7e7727569012453e643c2a9%5E%21 tdf#113849 ooxmlexport: even headers/footers for both or none. It will be available in 6.2.1. 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in 6.2 fully when comment 13's gerrit patch https://gerrit.libreoffice.org/67020 is accepted into 6.2.