Problem description: Steps to reproduce: 1. Open this file: https://www.dropbox.com/s/o158fpltxmsq5c9/Straniile.odt You should be able to see a red horizontal line bordering the header: http://prntscr.com/1g09h5 2. save is as .docx, .doc or pretty much any format (example here: https://www.dropbox.com/s/71k3nlgcko9jvp8/Straniile.doc 3 open the new file. The red line is gone: http://prntscr.com/1g0ag8 Current behavior: header border diaaperas when saving in another format Expected behavior: header border shoul remain visible when saving as .doc; .docx Operating System: Windows 7 Version: 4.0.4.2 release
Can confirm, setting to NEW. Tested on OS X 10.8.4, LO 4.1.0.2.0: Saving the odt to docx and then opening the docx file with LO results in the document missing the top line on each page.
Adam Co committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4b4bde0a28b06f150ec80a65e322491a547f803 fdo#67013 : fix for borders in headers and footers The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
May we close this item as fixed now? I see that Adam has made a commit to fix it, but I cannot check against the original report as the dropbox link appears to be broken.
Hi Luke, The issue seems to have been fixed with .docx documents, but not with .doc documents. See revised files for example: https://www.dropbox.com/sh/h1mmvc0027t17r8/zfUg6rUbb1 My LO version. is 4.1.2.3
** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Still reproducible for doc and docx. Windows Vista 64 Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 4.3.6.2 4.2.8.2 4.1.6.2
Created attachment 125688 [details] New test file the bug is still present in: Version: 5.3.0.0.alpha0+ Build ID: a8bd44573b75d1399257d6f5d052611439607189 CPU Threads: 2; OS Version: Linux 4.1; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-06-13_23:46:49 Locale: it-IT (it_IT.UTF-8) OS: openSUSE Leap 42.1 (x86_64)
The issue is still present in: Version: 5.3.0.0.alpha0+ Build ID: 54f2a4184d1296814e64cfeab1d06ae90d002357 CPU Threads: 2; OS Version: Linux 4.1; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-07-08_01:43:14 Locale: it-IT (it_IT.UTF-8); Calc: group OS: openSUSE Leap 42.1 (x86_64)
Microsoft Word does not actually support the concept of setting a border on a header/footer. If instead you set the border on the paragraph within the header, rather than on the header itself, then this comes through fine into doc or docx format. The same feature mismatch applies to background fill colour which can be set on the header/footer in LibreOffice but not in Microsoft Word. To resolve this issue, perhaps we could try to convert these header/footer properties into paragraph properties (or table properties etc) automatically when saving to Microsoft Word formats. This could give the expected result in most common cases, though it would still fail in harder cases e.g. see how hard it is in Word to put a border around multiple paragraphs which include a bulleted list: https://word.tips.net/T012034_Borders_on_Multiple_Paragraphs_with_Differing_Indents.html
** 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
hello, the same is reproducible with header and footer borders in LibreOffice Calc Version: 6.0.6.2.
Dear lo, 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
Repro 7.0+
Created attachment 165237 [details] Test compared LO MSO Repro 7.1+.
Confirmed when saved as .doc with: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38 Calc: threaded
(In reply to Luke Deller from comment #9) > Microsoft Word does not actually support the concept of setting a border on > a header/footer. Thus NOTABUG > If instead you set the border on the paragraph within the header, rather > than on the header itself, then this comes through fine into doc or docx This kind of emulation is not worth all the pitfalls it will cause.
NotABug is when something works, just needed an explanation. This would be NotOurBug then.