Download it now!
Bug 112195 (Whole-Page-Filling) - Allow image as full-page background to cover the whole page (see comment 19)
Summary: Allow image as full-page background to cover the whole page (see comment 19)
Status: VERIFIED FIXED
Alias: Whole-Page-Filling
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: László Németh
URL:
Whiteboard: target:6.3.0
Keywords:
: 70933 115018 115172 116814 121272 122868 (view as bug list)
Depends on: 103602
Blocks: Object-Fill Writer-Images Page-Style-Dialog 121668
  Show dependency treegraph
 
Reported: 2017-09-03 17:38 UTC by Lenge
Modified: 2020-04-21 14:36 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer, Impress, Draw all with background-size border and full (68.79 KB, application/x-zip-compressed)
2018-11-23 23:10 UTC, Regina Henschel
Details
Test file for CSS body margin formatting (whole-page background in browsers) (109 bytes, text/html)
2018-11-27 12:05 UTC, László Németh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lenge 2017-09-03 17:38:59 UTC
Description:
As proposed in bug 33041, comment 46, I suggest to generally allow page backgrounds to cover the entire page *including* the page margins. From the discussion at bug 33041, I have learned that this might involve extending ODF specifications.

However, the workaround proposed in bug 33041 suffers from bug 111779, and a "true" solution would make us more compatible with that other office suite. So it's probably worth the effort.

Steps to Reproduce:
See bug 33041

Actual Results:  
See bug 33041

Expected Results:
See bug 33041


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 Regina Henschel 2017-09-03 19:06:57 UTC
See discussion in Bug 103602. With my proposal to store the page filling properties in a <style:drawing-page-properties> element it would be possible to describe the desired behavior by the attribute draw:background-size in ODF.  http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-draw_background-size

Therefore I set a dependency here.

The element <style:drawing-page-properties> is already used for Draw and Impress documents. But its attribute draw:background-size is not implemented yet. The element can be used in Writer and Calc without extending the schema; only an addition in the description would be necessary in the ODF specification.
Comment 2 Regina Henschel 2017-10-24 09:36:36 UTC
The ODF TC has agreed to https://issues.oasis-open.org/browse/OFFICE-3937. So using the attribute draw:background-size in Writer and Calc too is possible in a way, that is conform to the schema.
Comment 3 Regina Henschel 2018-01-16 14:01:16 UTC
*** Bug 115018 has been marked as a duplicate of this bug. ***
Comment 4 Timur 2018-01-23 15:50:19 UTC
*** Bug 115172 has been marked as a duplicate of this bug. ***
Comment 5 Regina Henschel 2018-04-06 22:12:49 UTC
*** Bug 116814 has been marked as a duplicate of this bug. ***
Comment 6 Regina Henschel 2018-11-08 15:09:25 UTC
*** Bug 121272 has been marked as a duplicate of this bug. ***
Comment 7 László Németh 2018-11-23 19:49:41 UTC
Proposed fix: https://gerrit.libreoffice.org/#/c/63914/
Comment 8 Regina Henschel 2018-11-23 23:10:52 UTC
Created attachment 146989 [details]
Writer, Impress, Draw all with background-size border and full

It is not that simple. You need to implement reading and writing ODF too. The attribute is draw:background-size with its values "full" and "border". It belongs to the element <style:drawing-page-properties>. This is referenced by the draw:style-name attribute of the <style:master-page> element and of the <draw:page> element. Currently LibreOffice writes this element for .odp and .odg but it does not read it.
With ODF 1.3 you can use <style:drawing-page-properties> for Writer too. Already now it is valid against the ODF 1.2 schema.

The attachment has example documents, which I have changed, so that they use the <style:drawing-page-properties> element for the background. After an implementation of "background cover entire page" they should correctly show the background image in one version inside the content area and in the other version covering the margins.
Comment 9 László Németh 2018-11-26 21:29:55 UTC
(In reply to Regina Henschel from comment #8)
> Created attachment 146989 [details]
> Writer, Impress, Draw all with background-size border and full
> 
> It is not that simple. You need to implement reading and writing ODF too.

I think, in this case, Google Docs and MS Office have got the right ODT implementation, ie. those do the required (usable) thing, LibreOffice did the unnecessary (unusable) thing. See also the same similar good implementation of the CSS standard (CSS is the final reference in OpenDocument standard about page body background) with the following HTML test. Mozilla Firefox and Google Chrome do the same thing, coloring the page margin (or its background), there is no white border around the red text area:

<html>
<body style="margin: 2cm; background-color: red;">
    <p>Example</p>
</body>
</html>

(By the way, with @page rule it's possible to define page margins for paged media in CSS, and it's intended for example for page cropping by using negative values: https://www.w3.org/TR/CSS2/page.html, also cropping is a required feature of LibreOffice, especially in its PDF export)

The proposed (initial) patch doesn't modify the positioned and stretched background images yet, only the tiled one, limiting the possible minor*
compatibility issues. Solving them later we will be able to complete the DOCX compatibility, too, but it would be fine to fix those in LibreOffice 6.2, too.

*This was so broken feature with its difficult workarounds, that most affected users rather dropped OpenOffice.org/LibreOffice usage, for example, https://bz.apache.org/ooo/show_bug.cgi?id=9370#c16. I tried to wrap the annoying incompleteness of LibreOffice five years ago, but without real success: https://extensions.libreoffice.org/templates/striped-border
Comment 10 Regina Henschel 2018-11-27 01:18:06 UTC
(In reply to László Németh from comment #9)
> I think, in this case, Google Docs and MS Office have got the right ODT
> implementation,

Google Docs uses LibreOffice (currently LO 6.0.5) to create an odt-file. MS Word does not save a background color at all in odt-files. MS PowerPoint saves the color, but don't allow to set margins.

[..]
> The proposed (initial) patch doesn't modify the positioned and stretched
> background images yet, only the tiled one, limiting the possible minor*
> compatibility issues. Solving them later we will be able to complete the
> DOCX compatibility, too, but it would be fine to fix those in LibreOffice
> 6.2, too.

Making LibreOffice able to render a background filling, that colors the entire page, will be useless, if you cannot save the information "color entire page" in the file. I see nothing in your patch, that will do save and load.
Comment 11 László Németh 2018-11-27 11:55:16 UTC
(In reply to Regina Henschel from comment #10)
> (In reply to László Németh from comment #9)
> > I think, in this case, Google Docs and MS Office have got the right ODT
> > implementation,
> 
> Google Docs uses LibreOffice (currently LO 6.0.5) to create an odt-file. MS
> Word does not save a background color at all in odt-files. MS PowerPoint
> saves the color, but don't allow to set margins.

ODT import of Google Docs results correct whole-page background color. You are right, thanks, MS Word really ignores ODT page background, I've modified the description of the commit: https://gerrit.libreoffice.org/#/c/63914/. (Only the DOCX export of LibreOffice is correct, ie. whole page (only in) MS Office.)

> 
> [..]
> > The proposed (initial) patch doesn't modify the positioned and stretched
> > background images yet, only the tiled one, limiting the possible minor*
> > compatibility issues. Solving them later we will be able to complete the
> > DOCX compatibility, too, but it would be fine to fix those in LibreOffice
> > 6.2, too.
> 
> Making LibreOffice able to render a background filling, that colors the
> entire page, will be useless, if you cannot save the information "color
> entire page" in the file. I see nothing in your patch, that will do save and
> load.

It saves the same as before, but now it interprets it properly (no poor man's background coloring with white border, as before). It fixes also the DOCX import, and it exports PDFs with whole-page background, too. I think, this is a very important competitive feature, and it should have been fixed this way a long ago, because the recent form is really annoying and unusable (in fact, it's a shame :).

(This fix is similar to the recent changes of the text coloring: LibreOffice opens also the old ODTs with white text color on dark background color, changing the original layout. Maybe it's not perfect, but much better, than before.)

Thanks for your help, Laszlo
Comment 12 László Németh 2018-11-27 12:05:15 UTC
Created attachment 147064 [details]
Test file for CSS body margin formatting (whole-page background in browsers)
Comment 13 Commit Notification 2018-11-27 13:45:52 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/f006b6339e20af6a3fbd60d97d21590d4ebf5021%5E%21

tdf#112195 Writer: page background covers whole page

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.
Comment 14 László Németh 2018-11-27 13:57:26 UTC
I pushed my initial fix to the master for testing purpose.

I guess, bigger amount of DOCX will be affected (fixing their layout), that ODT in our test document database, because ODT background-modification is almost unused feature with its fundamental visual glitch (that is why I mentioned it as a poor man's version of the intended page background settings.)

Xisco: could you report the result with the affected ODT and DOC/DOCX test files, please? Thanks, Laszlo

Regina: I've made some further competitive analysis. Office 365 hides all background settings, ODT's and DOCX's, but it can export correct PDF from DOCX. Office 365 and MS Word export PDFs with different bitmap background from the same DOCX created in MS Word 2016 (Word's export has a 18 tiles, Office 365's export has got 3 tiles. Office 365 doesn't show anything, MS Word shows only a small part of the background image. So bitmap background is not a perfect feature in MS Word, but at least it is a whole page background.
Comment 15 László Németh 2018-11-27 14:06:26 UTC
This is not an enhancement, but a bug, because we have to change the broken page background feature of LibreOffice according to the graphic design requirements and usability.
Comment 16 Dieter 2019-01-04 20:23:35 UTC
I could cover whole page with background colour in

Version: 6.3.0.0.alpha0+ (x64)
Build ID: ffa5b8a82eab18041bbee4d6914892b82c7801d3
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-12-19_03:24:54
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

So can we close this bug?
Comment 17 László Németh 2019-01-04 20:36:17 UTC
I've close this. For the other problems, ie. full-page background picture, please file a new issue.

@Dieter: thanks for the your feedback.
Comment 18 Thomas Lendo 2019-01-05 21:28:12 UTC
To make it possible to have a other-colored margin (the area that wasn't colored until 6.3) I suggest:
- Bug 85860 - border lines and spacing should optionally increase frame size rather than reduce content to fit (this bug should be extended also to page settings)
- Bug 122511 - Thicker border line than 9 pt or 5 cm
Comment 19 Lenge 2019-01-06 11:45:12 UTC
Reopening. As for comment 17, please note that I have created THIS issue exactly for the case of a full-page background letterhead picture issue (as a leftover from bug 33041, which provided a workaround but no final solution).

Dragging this from bug to bug to bug is not a good idea, especially as Regina's valuable background infos could easily get lost. So please keep it open until it is finally resolved.
Comment 20 Xisco Faulí 2019-01-22 13:19:40 UTC
*** Bug 122868 has been marked as a duplicate of this bug. ***
Comment 21 Volga 2019-05-24 03:24:58 UTC
It's now possible to fill the page background to the whole page in version  6.3.0.0.alpha1.
Comment 22 Thomas Lendo 2019-05-24 07:03:59 UTC
How is it possible to have a margin with LibO 6.3 like in the attached screenshot with LibO 6.0? https://bug-attachments.documentfoundation.org/attachment.cgi?id=151652
Comment 23 Dieter 2019-05-24 07:22:03 UTC
(In reply to Lenge from comment #19)
> Reopening. As for comment 17, please note that I have created THIS issue
> exactly for the case of a full-page background letterhead picture issue (as
> a leftover from bug 33041, which provided a workaround but no final
> solution).

=> I changed bug title to make it more clear.
Comment 24 Volga 2019-05-26 10:50:43 UTC
(In reply to Volga from comment #21)
> It's now possible to fill the page background to the whole page in version 
> 6.3.0.0.alpha1.
I just set page background in version 6.2.3.2, and the margin is still white, but when I open the file in LODev, the background is covering the whole page.
Comment 25 Dieter 2019-06-05 15:42:25 UTC
This bug was changed to RESOLVED FIXED after comment 17. I don't see a reason, why it was reopened. Bug 122508 is a followup.

=> change status again to RESOLED FIXED
Comment 26 Dieter 2019-07-12 14:56:21 UTC
I confirm, that it is fixed in

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-10_02:13:57
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

=> VERIFIED FIXED
Comment 27 Justin L 2020-03-18 18:43:17 UTC
*** Bug 70933 has been marked as a duplicate of this bug. ***
Comment 28 Mike Kaganski 2020-04-21 03:55:27 UTC
FTR: as mentioned in bug 33041 comment 48:

> IMO implementing such a high-impact change without a compatibility option to
> allow existing documents to stay intact is *wrong*. And now there's a real-life
> question about this:

> https://ask.libreoffice.org/en/question/208634/white-margins
Comment 29 Lenge 2020-04-21 10:12:13 UTC
(In reply to Mike Kaganski from comment #28)
> FTR: as mentioned in bug 33041 comment 48:
> 
> > IMO implementing such a high-impact change without a compatibility option to
> > allow existing documents to stay intact is *wrong*. And now there's a real-life
> > question about this:
> 
> > https://ask.libreoffice.org/en/question/208634/white-margins

Over the years, there have been many real-life questions for the exact opposite; see all the corresponding bug reports concerning background colors and/or images not being able to cover the entire page.

So the worst thing to do is still NOT enabling it just for the sake of backwards compatibility.

Having that said, I'd still like to have a compatibility option like "[x] Limit background to page margins" that would be enabled for older documents.
Comment 30 Mike Kaganski 2020-04-21 10:28:31 UTC
(In reply to Lenge from comment #29)
> Over the years, there have been many real-life questions for the exact
> opposite; see all the corresponding bug reports concerning background colors
> and/or images not being able to cover the entire page.
> 
> So the worst thing to do is still NOT enabling it just for the sake of
> backwards compatibility.

This is skewed perception. If you have something implemented this way, and some people need it implemented that way, guess who will you hear from over the years? Do you think that those who are OK with the status quo would raise their voices? Of course only those who need the other way would ask for change. That doesn't mean that there's no need in current implementation.

But the problem here is not that the change was made, but that it was not accompanied with a compatibility setting, which is *normal practice* in the LibreOffice, and the author of the change is aware of it. Please don't write things like in comment 29, which shifts the focus from the actual point into discussing what wasn't proposed ("NOT enabling it").
Comment 31 László Németh 2020-04-21 11:23:46 UTC
@Mike: As I wrote in comment 9 and comment 11, this was a fix for the bad interpretation of OpenDocument page background standard. You are right about the possible and existing back compatibility issues, but as Lenge pointed out, this is still a huge improvement for normal usage and interoperability, rather than a minor regression for a few users. You are absolutely right about the compatibility setting, but I wasn't able to add that (this bug was a very low priority task, so it was near fixed in my free time).

If I can ask for your and Regina's help in a similar problem, could you check Bug 114141, please? I wanted to create a compatibility settings, there, or much better, to support both layout of 3D charts, but the first version of the patch was accepted and merged accidentally by the expert of the area...
Comment 32 juh+bugzilla-documentfoundation 2020-04-21 11:38:05 UTC
I was one of the users that asked for this feature in a bug report many years ago. 

I don't use LibreOffice for most of my use cases as I would need this feature. Luckily there is LaTeX and (in my case) ConTeXt.
Comment 33 Mike Kaganski 2020-04-21 14:10:55 UTC
(In reply to László Németh from comment #31)
> You are absolutely right
> about the compatibility setting, but I wasn't able to add that (this bug was
> a very low priority task, so it was near fixed in my free time).

Just in case, if you would need to introduce a compat flag somewhere, something like in https://git.libreoffice.org/core/+/0cb200d000fad8ba31c7400e08cd031823f27308 might be useful. Of course, now here it's not needed, because now we have some documents generated using released versions 6.3 and 6.4, which already rely on new behaviour without any flags.

> If I can ask for your and Regina's help in a similar problem, could you
> check Bug 114141, please? I wanted to create a compatibility settings,
> there, or much better, to support both layout of 3D charts, but the first
> version of the patch was accepted and merged accidentally by the expert of
> the area...

Replied there. Sorry if I am not knowledgeable in charts.
Comment 34 László Németh 2020-04-21 14:36:46 UTC
(In reply to Mike Kaganski from comment #33)

Many thanks for the code pointer and checking the chart issue!