Problem description: docx refuses to keep the background color (changes color back to white). Steps to reproduce: 1. open "page" under "format" 2. change all margins to 0 3. click on background tab (then click yes) then click and choose any "obvious it's not white" color. 4. click on the borders tab. click on "set all four borders" box(2nd option under the "default" options) 5. change "spacing to contents" to 1 inch or whatever you like (changing one automatically changes them all). 6. click on ok. save, close, and reopen document. Current behavior: changes page/background color back to white. Expected behavior: to keep the whole page/background the color i specify. Operating System: Windows 7 Version: unspecified
Please don't add your own bug to the MAB list as it's against policy unless a developer or QA person has asked you to do so. Also the appropriate status is UNCONFIRMED until it's verified by an independent QA person
So it looks like this has been fixed in 4.2 branch - I can confirm on 4.1 branch but 4.2 branch is resolved. Tested on Ubuntu 13.04 Michael - think we can locate what patch fixed this and backport it to 4.1? Because this is a data loss bug, hopefully we can locate it.
Please also don't push your own bug on the MAB - these policies are in place to prevent people from spamming their own bugs to the list. Please keep all comments on this bug and QA will decide if it should be on MAB list. As a matter of policy, this one will not get on the list as it's fixed in 4.2 so technically it could be set to WORKSFORME - but we are trying to track down the patch so we can backport it
By "please don't push" I mean - please do not leave any comment on the MAB tracker bug - comments on that bug should only be by devs and QA explaining why a bug is added to the list by someone who knows the policies of what constitutes a most annoying bug
i tested it out on 4.2alpha0+ and the header and footer still reset themselves to white. something i noticed (in 4.2alpha0+): in the "borders" tab the "left" and "right" "spacing to contents" stay as i have set them upon reopening but the "top" and "bottom" change themselves (upon reopening) to "0" AND under the "page" tab the "top" and "bottom" margins change themselves to the numbers that were in the "top" and "bottom" of "spacing to contents".
I am testing under master not alpha, perhaps it was fixed between alpha and my build of master which was just 2 days ago. You mind testing daily build found here: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2013-10-27_23.53.26/
i tested it ( http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2013-10-27_23.53.26/ ) and the header and footer still revert back to white when i reopen the docx file. (i'm using windows 7 32-bit)
*more specifically the microsoft word 2007/2010 docx
I will retest on my Windows 8 machine to see what results I see - on Linux I definitely see the problem in 4.1 but not 4.2. One more question, you mind resetting your profile with the daily build? https://wiki.documentfoundation.org/UserProfile Thanks for the help. I'm going to take it a level further and see if you have some time to help test Windows bugs in general - we need some help with triaging Windows bugs, if you have some time - shoot me an email and I'll help you get started :) Thanks!
** 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.1 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-04-01
(In reply to esafe11 from comment #5) > i tested it out on 4.2alpha0+ and the header and footer still reset > themselves to white. something i noticed (in 4.2alpha0+): in the "borders" > tab the "left" and "right" "spacing to contents" stay as i have set them > upon reopening but the "top" and "bottom" change themselves (upon reopening) > to "0" AND under the "page" tab the "top" and "bottom" margins change > themselves to the numbers that were in the "top" and "bottom" of "spacing to > contents". Reproduced. Win 7 Pro 64-bit Version: 5.0.0.0.alpha0+ (x64) Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17 Locale: fi_FI
** 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 (5.1.5 or 5.2.1 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Created attachment 143748 [details] colorPage.odt: 30 pt border, zero page margins If I remember correctly, .docx format can only have a small spacing by the borders. So LO has to emulate this. Confirming that the border becomes zero, and all the spacing has been transferred to the page margins.
Dear esafe11, 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
fix in LO 6.3 with commit f006b6339e20af6a3fbd60d97d21590d4ebf5021 Author: László Németh Date: Fri Nov 23 21:55:54 2018 +0100 tdf#112195 Writer: page background covers whole page as in ODT implementation of Google Docs, and as in DOCX supporting basic requirements of creating digital and professional print media. This patch fixes DOCX import (tdf#121668) and it gives the required PDF export, too. In the case of solid color, color gradient, hatching, pattern and tiled bitmap (except stretched bitmap), this patch removes the obsolete white border around the text area, if the user modifies the page background. Note: likely the white border was good for home printing in former times, but now it forms only a serious barrier for most users to create de facto design standard whole page background formatting instead of its unacceptable poor man's version. Note 2: the OpenDocument standard refers XSL/CSS here, and browsers adapt background settings to the body margin area the same way, as Google Docs and fixed LibreOffice do. More information: tdf#112195 "(Whole-Page-Filling) - Allow page background to cover the whole page (reloaded)" tdf#33041 "Allow page background to cover the whole page, not only within page borders/margins" tdf#121668 "FILEOPEN DOCX Page Color created with Word disappears on the margins" ooo#9370 "Off-margin page background" (https://bz.apache.org/ooo/show_bug.cgi?id=9370) *** This bug has been marked as a duplicate of bug 112195 ***