Bug 70933 - FORMATTING: docx changes certain page format background color upon reopening
Summary: FORMATTING: docx changes certain page format background color upon reopening
Status: RESOLVED DUPLICATE of bug 112195
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Windows (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: filter:docx
Depends on:
Blocks: DOCX-Page
  Show dependency treegraph
 
Reported: 2013-10-27 20:35 UTC by esafe11
Modified: 2020-03-18 18:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
colorPage.odt: 30 pt border, zero page margins (7.75 KB, application/vnd.oasis.opendocument.text)
2018-07-25 12:08 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description esafe11 2013-10-27 20:35:53 UTC
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
Comment 1 Joel Madero 2013-10-27 20:54:39 UTC
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
Comment 2 Joel Madero 2013-10-27 22:19:22 UTC
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.
Comment 3 Joel Madero 2013-10-27 22:49:49 UTC
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
Comment 4 Joel Madero 2013-10-27 22:51:10 UTC
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
Comment 5 esafe11 2013-10-28 01:33:16 UTC
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".
Comment 6 Joel Madero 2013-10-28 01:50:36 UTC
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/
Comment 7 esafe11 2013-10-28 21:48:13 UTC
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)
Comment 8 esafe11 2013-10-28 21:50:00 UTC
*more specifically the microsoft word 2007/2010 docx
Comment 9 Joel Madero 2013-10-28 23:03:51 UTC
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!
Comment 10 QA Administrators 2015-04-01 14:40:59 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2015-04-22 14:41:39 UTC
(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
Comment 12 QA Administrators 2016-09-20 09:33:33 UTC Comment hidden (obsolete, spam)
Comment 13 Justin L 2018-07-25 12:08:20 UTC
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.
Comment 14 QA Administrators 2019-07-30 03:17:05 UTC Comment hidden (obsolete, spam)
Comment 15 Justin L 2020-03-18 18:43:17 UTC
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 ***