Created attachment 122791 [details] Conversion Examples We have a number of test documents which we want to convert from ODT to DOCX format. Herein we see a number of issues (see attachments for details): Opmaakprofielen.odt > Opmaakprofielen.docx * Page 1: Borders around the paragraph are not properly restored * Page 2: Image is not restored in DOCX * Page 2: The "adres" table, which is part of the header, is reproduced at the correct location, but the size of the header is too small (compared to LibreOffice ODT), which causes the tekst "Eerste pagina profiel" to appear too high. Ontvangsbewijs.odt > Ontvangstbewijs.docx * Header: the text "Dienst ruimtelijke ordening" appears above the logo in the converted document (DOCX), while it is effectively below the logo in the original document. This appears to be caused by sizing of the header again.
It's highly unlikely that any bugs of type "multiple problems/bad rendering", will be fixed, so this bug shouldn't be confirmed. Each issue (section break, paragraph break, text box, picture...) should be reported separately, after a search for already reported bugs. Only if bugs don't exist, they should be reported separately, even if they happen with the same file.
Changed this report to only contain the issue about the header height where something goes wrong. It appears to me caused by the height of the header. So the problem statement of this issue is narrowed down to: Opmaakprofielen.odt > Opmaakprofielen.docx * Page 2: The "adres" table, which is part of the header, is reproduced at the correct location, but the size of the header is too small (compared to LibreOffice ODT), which causes the tekst "Eerste pagina profiel" to appear too high. Ontvangsbewijs.odt > Ontvangstbewijs.docx * Header: the text "Dienst ruimtelijke ordening" appears above the logo in the converted document (DOCX), while it is effectively below the logo in the original document. Caused by the height of the header which seems to be incorrectly converted For the other items, I'll do a further search and create new issues (if needed).
Reproduced by saving odts to docxes. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: ef02de2698d90fd874bddf3146165cbe85487bc5 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-19_23:40:50 Locale: fi-FI (fi_FI)
bibisected-43all indicates a regression in LO4.2 # good: [e33eaf662f84503c8de782d6677d9eb1b0b0d96b] source-hash-6c3d74e8b779b1eb2d9779ed84f1518e078113c4 # first bad commit: [f2554751603ad8537257b3cf52d6171056c76eeb] source-hash-f42768fe0b60ecbbe9c68d775329bf28c0690131 I don't have a good guess as to which of those commits caused the problem.
(In reply to Justin L from comment #4) > I don't have a good guess as to which of those commits caused the problem. The linux 43all bibisect appears to be misleading, even though I double-checked the results. I have made a clean compile of last41onmaster and exhibited the same problem - the text appears above the logo. last41onmaster: f160e4935c474a5293b3d3c11b3d538efb4767a0 CommitDate: Mon May 20 14:30:50 2013 +0300 I failed to compile last40onmaster (precise 12.04). Marking as non-bibisectable. Perhaps someone can run a MacOS bibisect to see if they get different results.
bibisected with the new 42max set. Unfortunately it ran into a string of 16 commits where office wouldn't start. The last good commit was 40ff64b93fc4c4c2e2710853e9f71e35811b9362 Author: Eike Rathke <erack@redhat.com> CommitDate: Fri Aug 30 13:54:48 2013 +0200 and another one for fdo#68740 so the bad commit is somewhere between that one and the next time that LO could start again, which was commit 47924a46566352dd99a14163d98bd2b51cca6b0e Author: Julien Nabet <serval2412@yahoo.fr> CommitDate: Fri Aug 30 20:58:07 2013 +0200 Revert "-Werror=unused-but-set-variable bCategoriesApplied" My guess would be that it was caused by author Michael Stahl <mstahl@redhat.com> 2013-08-30 17:13:40 (GMT) commit f8307e5ae11e8235fa1fb88ed52625bf9c650dc2 fdo#41068: writerfilter: fix image wrap polygon import but things have really moved around alot since then: commit 003434f1e2f4bd7ec08d2428fe2b90c11e680cef Author: Jan Holesovsky <kendy@collabora.com> Date: Tue Jul 15 07:25:38 2014 +0200 fdo#76803: Kill resourcemodel::Fraction, and use Fraction from tools instead.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I tried to take the original .ODT files and change the page-breaks into "page-break-with-style" and the program failed to do that properly. So I'm not going to bother looking into this further since the UI doesn't even work with this document - perhaps because of all of the shapes. I expect OP's problem to be related to next-style pointing to a different style which has a much different header size, and the page-break just being a simple one instead of being explicit about what page style should be applied.
Yeah, so this one will require export logic something like: if regular page break and page-style-before has a follow style then change page break into page break with style .DOC format already does this. So very likely there are common situations where NOT doing this is desirable. Thus, I like having doc and docx do things differently sometimes - that way at least one compatible format should fit the bill. [But let me look a bit further into DOCX to see if maybe the logic can be tweaked.]
So, these two synerzip commits look really, umm, interesting - like a "fix my one document so that it works" kind of fixes. 4.3 commit a31fbb53dba76736b37213b98b64937f05929a67 Author: Pallavi Jadhav on Thu Feb 6 13:58:03 2014 +0530 tdf#74566:DOCX: Preservation <w:br> tag for Break to Next Page Issue : 'Break to Next Page' gets converted to 'Page Break Before' in RT. XML diffrenece : - LO exports <w:br> as <w:pageBreakBefore /> in document.xml - The page break is written into wrong paragraph. Implementation : 1] Removed implementation to export <w:pageBreakBefore />. 2] Added a check to write <w:br> in correct paragraph. 3] Modified code to handle SectionBreak() even if Text node has no string. It is required when DOCX contains a PageBreak with footer. 4] Written Export Unit Test case. and 4.3 commit e9b2787c2ece4c8260fbac6359257e1829c917d4 Author: umeshkadam on Fri May 2 13:25:15 2014 +0530 tdf#77890: page break exported as section break if different 1st page is set - Page break was getting exported as section break in case if the different first page was set. - Fixed this issue and added a UT. - For additional details regarding the issue please check the following https://www.libreoffice.org/bugzilla/show_bug.cgi?id=77890#c2
proposed fix at http://gerrit.libreoffice.org/c/core/+/99171
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/140e8861566afcd1c51ede4bafd9ac2c6192cd68 tdf#98000 docx export: blank paragraphs don't affect page breaks It will be available in 7.1.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 "master": https://git.libreoffice.org/core/commit/4b2f0758c99e7b50293d965699f2125ff79bee17 tdf#98000 docx export: cleanup obsolete clause It will be available in 7.1.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 "master": https://git.libreoffice.org/core/commit/f19dd5a6d3b65556f6dfb8ee0e52333e422733f0 NFC tdf#98000 docx export: more general code cleanup It will be available in 7.1.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.
Real detective work done here by Justin. I put mentioned bugs to See Also.