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
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.
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.
*** Bug 115018 has been marked as a duplicate of this bug. ***
*** Bug 115172 has been marked as a duplicate of this bug. ***
*** Bug 116814 has been marked as a duplicate of this bug. ***
*** Bug 121272 has been marked as a duplicate of this bug. ***
Proposed fix: https://gerrit.libreoffice.org/#/c/63914/
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.
(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
(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.
(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
Created attachment 147064 [details] Test file for CSS body margin formatting (whole-page background in browsers)
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.
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.
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.
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?
I've close this. For the other problems, ie. full-page background picture, please file a new issue. @Dieter: thanks for the your feedback.
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
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.
*** Bug 122868 has been marked as a duplicate of this bug. ***
It's now possible to fill the page background to the whole page in version 6.3.0.0.alpha1.
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
(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.
(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.
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
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
*** Bug 70933 has been marked as a duplicate of this bug. ***
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
(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.
(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").
@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...
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.
(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.
(In reply to Mike Kaganski from comment #33) Many thanks for the code pointer and checking the chart issue!