Bug Hunting Session
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:
: 115018 115172 116814 121272 122868 (view as bug list)
Depends on: 103602
Blocks: Object-Fill Writer-Images Page-Dialog 121668
  Show dependency treegraph
 
Reported: 2017-09-03 17:38 UTC by Lenge
Modified: 2019-07-12 14:56 UTC (History)
13 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 Praas 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 Praas 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 Praas 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 Praas 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