Bug 33041 - Allow page background to cover the whole page, not only within page borders/margins (workaround in comment 33)
Summary: Allow page background to cover the whole page, not only within page borders/m...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard: interoperability
Keywords: needsDevEval
: 53331 67301 79286 90167 93165 142972 (view as bug list)
Depends on: 41542
Blocks: Object-Fill Page-Style-Dialog
  Show dependency treegraph
 
Reported: 2011-01-12 14:36 UTC by Ihar Filipau
Modified: 2021-07-23 12:58 UTC (History)
20 users (show)

See Also:
Crash report or crash signature:


Attachments
the non-white bg test .odt (9.28 KB, application/vnd.oasis.opendocument.text)
2011-01-12 14:36 UTC, Ihar Filipau
Details
resulting pdf (11.71 KB, application/pdf)
2011-01-12 14:37 UTC, Ihar Filipau
Details
LO screenshot with the .odt open (60.05 KB, image/png)
2011-01-12 14:38 UTC, Ihar Filipau
Details
Document with entirely black background of page (25.74 KB, application/vnd.oasis.opendocument.text)
2012-11-26 14:00 UTC, sasha.libreoffice
Details
Document with the described workaround (33.85 KB, application/vnd.oasis.opendocument.text)
2016-09-05 19:00 UTC, Regina Henschel
Details
docx with pink bg (12.31 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-08-17 15:46 UTC, Yan Pas
Details
abiword files (13.06 KB, application/zip)
2017-08-17 18:59 UTC, Yan Pas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ihar Filipau 2011-01-12 14:36:50 UTC
Created attachment 41935 [details]
the non-white bg test .odt

Changing page background still leaves the borders white.

I wanted to create a document not for printing - but suited for reading on screen. The document is to be converted into a PDF. For the content I need a non-white (dark) background to go along with the embedded graphics.

Yet when I change the page background (Format > Page... > Background tab) to e.g. black color (same effect for any other color and graphics), the backgound doesn't cover the whole page - it covers only the space with text, always leaving the borders white.

Attached are:
- the .odt
- the resulting .pdf
- screen shot
Comment 1 Ihar Filipau 2011-01-12 14:37:36 UTC
Created attachment 41936 [details]
resulting pdf
Comment 2 Ihar Filipau 2011-01-12 14:38:13 UTC
Created attachment 41937 [details]
LO screenshot with the .odt open
Comment 3 Rainer Bielefeld Retired 2011-01-19 02:58:33 UTC
That's not only a WRITER-Problem, but I agree that for some affairs (greeting PDF letters) that's most annoying in WRITER. Workaround: no page borders, text in text frame, so background will cover full page without white borders.

I agree, especially for creation of PDF documents that would be a very nice feature
Comment 4 Lenge 2011-10-04 09:30:06 UTC
Something very similar has been a really long-standing request for "Upstream OOo":

https://issues.apache.org/ooo/show_bug.cgi?id=9370

The above link contains some more information, suggestions and usages of such a feature One of the most important pros of this feature is enabling the use of full-page background images (e. g. for letterheads) without "violating" the page margin concepts in order to practice one of the presented workarounds.
Comment 5 Björn Michaelsen 2011-12-23 11:47:56 UTC Comment hidden (obsolete)
Comment 6 Ihar Filipau 2011-12-24 05:49:05 UTC
3.5.0b2, Windows x86, the issue is still present.

Changing status to NEW as per the spambot instructions.
Comment 7 Rainer Bielefeld Retired 2011-12-24 07:12:00 UTC
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 8 Christian Lohmaier 2012-08-10 10:58:45 UTC
*** Bug 53331 has been marked as a duplicate of this bug. ***
Comment 9 sasha.libreoffice 2012-11-26 14:00:30 UTC
Created attachment 70589 [details]
Document with entirely black background of page

I have created document which have entirely black background. It correctly exports to PDF. This document may be used for producing needed PDFs for screen reading until this bug will be fixed (workaround).
Comment 10 Rainer Bielefeld Retired 2012-11-26 14:11:10 UTC
@sasha:
Nice trick, thx!
Comment 11 Owen Genat (retired) 2013-08-03 05:40:23 UTC
*** Bug 67301 has been marked as a duplicate of this bug. ***
Comment 12 Yousuf Philips (jay) (retired) 2014-05-27 16:43:45 UTC
*** Bug 79286 has been marked as a duplicate of this bug. ***
Comment 13 Buovjaga 2015-09-05 17:36:09 UTC
*** Bug 90167 has been marked as a duplicate of this bug. ***
Comment 14 Buovjaga 2015-09-05 17:37:59 UTC
*** Bug 93165 has been marked as a duplicate of this bug. ***
Comment 15 Yan Pas 2015-09-06 13:58:33 UTC
Why Importance is "medium - enhacment"? LO Writer behaves wrong, so it's at least "medium - normal". I didn't find any criteria how to set it (https://wiki.documentfoundation.org/QA/Bugzilla/Fields where?), but sometimes it's difficult to create background you need in external rastor graphics editor (sometimes you don't have it or don't know how to use it). And working with document with image on background is uncofortable (image sometiems is selected). So importance should be higher I guess
Comment 16 Yousuf Philips (jay) (retired) 2015-09-07 08:01:29 UTC
Not sure whether this should be classified as an enhancement or a bug (AOO bug tracker has it as enhancement as well), but in my book it would be a bug, as when you set the background/area of a shape or frame, it fills the entire shape and not just the space that text can be written in. We are setting the page background/area and not the margin background/area, but this might be a limitation of the ODT format, as calligra opens it in a similar fashion.

But this issue causes compatibility/interoperability problems when importing and exporting documents from other formats (e.g. docx), where the page background fills the entire page.

A somewhat plausible workaround for this is to set the page margins to 0.00" and then enable borders and set spacing to contents to 0.79", though the border will still be present. :)
Comment 17 Yan Pas 2015-09-07 15:53:40 UTC
I don't think ODT describes how page background should be applied, ODT may have only lack of options ( i. e. it has only option "Page Background", not "Margins background" and "Page without margins background" ). And office suite may interpet one way or another. E. g. Abiword applies background to entire page for the odt which was created and edited in LO. As far as I remember (don't have possibility to run MS Word 2013+ now) MS Word opens such ODTs with background applied to entire page. But MS Word applies background to entire page for doc/docx saved in LO for sure.

So once again, format doesn't describe whether to apply background for margins or not, office suite to decide how to do it. MS Word, Apple Work, Google Docs, Abiword apply background to entire page.

One issue, that wasn't mentioned here is compatibility. (There is a quote by TDF, smth like "LO guarantees you that your docs will look the same since 20 years"). So the document will look differently when the bug will be fixed.
I think that's OK, I can't imagine document that will look better with with white margins. But someone may get benefits from this bug. For example someone printed document with white margins, and wrote some notes on white space.
Comment 18 mailbox 2015-09-07 16:50:44 UTC
(In reply to Yousuf (Jay) Philips from comment #16)
> Not sure whether this should be classified as an enhancement or a bug (AOO
> bug tracker has it as enhancement as well), but in my book it would be a
> bug

+1 this is a bug IMO

(In reply to Yan Pashkovsky from comment #17)
> One issue, that wasn't mentioned here is compatibility. (There is a quote by
> TDF, smth like "LO guarantees you that your docs will look the same since 20
> years").

You raise a valid point, but IMO, it seems overly nuanced not to fix this bug because of compatibility.  It seems most logical and consistent to treat the page background as just that, not just as a text-area background.  I cannot think of any professional publications with text margins that do not extend background design elements to page edges.

The "notes in the margins" scenario also feels like an edge-case (no-pun-intended), as anyone wanting to scribble on a printed document could/should remove the background, and/or downsize the document when printing for review (I'm thinking PDF/driver print options).
Comment 19 Yan Pas 2015-09-07 18:28:23 UTC
So you think that there should be no options to choose whether to put background on margins or not. I agree with you that current behavior is wrong. And I doubt that ODT supports boolean for margins background. The only option I see for solving compatibility issues is tick in LO settings, but it's definitely bad solution. (Requesting this boolean for ODF v. 1.2.1 is silly and too long)

>The "notes in the margins" scenario also feels like an edge-case
Yes, people may attach white rectangle to footer or header.

I do not see any good way to implement compatibility, maybe someone will suggest. Then I vote that it is BUG too, documents will be looking more correctly, not differently. In conclusion, everyone thinks that it is bug, no one thinks that it is FEATURE-REQUEST(ENHACEMENT).
Comment 20 Robinson Tryon (qubit) 2015-12-13 11:21:43 UTC Comment hidden (obsolete)
Comment 21 Cor Nouws 2016-09-05 15:01:00 UTC Comment hidden (obsolete)
Comment 22 Cor Nouws 2016-09-05 15:05:30 UTC
(In reply to Cor Nouws from comment #21)
> (how can one ever find this bug when the component is UI :\ )

But obviously it's not only Writer > component LibreOffice
Comment 23 Yousuf Philips (jay) (retired) 2016-09-05 17:03:49 UTC
@regina: Is this a limitation of ODF or is this just a bug in LO?
Comment 24 Regina Henschel 2016-09-05 18:25:51 UTC
The settings are in element <style:page-layout-properties> in ODF. It allows the attributes fo:margin and fo:padding. The namespace fo belongs to XSL,e.g https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#padding-top. The specification of XSL refers to CSS and there you find the box model https://www.w3.org/TR/REC-CSS2/box.html#box-padding-area.

The "margin"-area is always transparent. The "padding"-area has the same background as the content-area. The border is between "margin"- and "padding"-area. So margins can never have a background.

The solution for LibreOffice can be, to allow to set a padding without having a border. border-width="0pt" is handled the same as border="none" in XSL, so allowing "no" border is no problem in regard to specification. "padding" is the setting "Spacing to contents" in the tab Borders in the page style dialog. Currently padding is disabled, if no border is set. But having border width = "0pt" is allowed in CSS and in turn in ODF.

In case LO would allow padding without border, the user could set margin to 0pt and determine the needed distance between text and page edge be setting a suitable padding. Because the padding has the same background as the content, then the image would be drawn up to the page edge.

As workaround, you currently set margins to 0cm (and ignore printer warning), and set the border to the smallest possible value and to a color, which makes it rather invisible (background color of page, or similar to an image color, for example). You get a document with a minimal border at the page edge and an image covering the whole page. Most printers have a non-printable area and will not print near the paper edge, regardless what the document page has there. Only in PDF you will see this small border.

The same problem exists not only for page layout, but in all other cases, where you can set border and padding.
Comment 25 Cor Nouws 2016-09-05 18:39:52 UTC
Thanks Regina,

(In reply to Regina Henschel from comment #24)

> The solution for LibreOffice can be, to allow to set a padding without
> having a border. border-width="0pt" is handled the same as border="none" in
> XSL, so allowing "no" border is no problem in regard to specification.
> "padding" is the setting "Spacing to contents" in the tab Borders in the
> page style dialog. Currently padding is disabled, if no border is set.

But setting a border in a page style, doesn't offer me a UI to set the padding, does it?

> As workaround, you currently set margins to 0cm (and ignore printer

So then this workaround has no option to set a padding, so there is no difference between the border edge (background to the side of the paper) and the content edge (e.g. text) ?
Comment 26 Regina Henschel 2016-09-05 18:50:50 UTC
(In reply to Cor Nouws from comment #25)

> But setting a border in a page style, doesn't offer me a UI to set the
> padding, does it?

The UI is there. "margin" in the sense of specification is the setting "Margin" in tab "Page" of the page style dialog. "border" in the sense of specification is the setting "Line width" o.a. in the tab "Borders" of the page style dialog. "padding" in the sense of specification is the setting "Spacing to Contents" in the tab "Borders".

The only problem is, that LO disables "Spacing to Contents" in case "Line Arrangement" is set to "none" in the tab "Borders", whereas the specification allows such setting.
Comment 27 Yan Pas 2016-09-05 18:57:31 UTC
Documents created in MS Word with page backgorund and saved in both ODT and DOCX don't have any white borders. If you open these docs in LO then the borders become white.
And vice versa, if you create doc with page bg in LO and then open it in MSO - there will be no white borders.

So it's most likely LibreOffice's problem
Comment 28 Regina Henschel 2016-09-05 19:00:25 UTC
Created attachment 127160 [details]
Document with the described workaround
Comment 29 Cor Nouws 2016-09-05 19:03:17 UTC
(In reply to Regina Henschel from comment #26)

Ah, in current LibreOffice terms : margin 0; border ~0, Spacing to contents = x (the margin you want for the content).
Comment 30 Lenge 2016-09-05 20:22:07 UTC
(In reply to Regina Henschel from comment #26)
> The only problem is, that LO disables "Spacing to Contents" in case "Line
> Arrangement" is set to "none" in the tab "Borders", whereas the
> specification allows such setting.

If I understand correctly, allowing this in LibreOffice would be a suitable approach to resolve the full-page background issue, and at the same time also resolve bug 41542. Am I right?

(However, I'd suggest to have the LibreOffice UI not deal with the CSS terms of "margin" vs. "padding" as these can easily become confusing.)
Comment 31 Regina Henschel 2016-09-05 20:39:58 UTC
(In reply to Lenge from comment #30)
> If I understand correctly, allowing this in LibreOffice would be a suitable
> approach to resolve the full-page background issue, and at the same time
> also resolve bug 41542. Am I right?

Yes, it is the same problem. The solution in file format is the same. The position where something in the code has to be changed, is likely different.
Comment 32 Michael Stahl (allotropia) 2016-09-26 11:38:15 UTC
possibly related OASIS issue:
https://issues.oasis-open.org/browse/OFFICE-3769
Comment 33 Justin L 2016-11-26 08:17:27 UTC
As of LibreOffice 5.4, this issue could potentially be closed - workaround enabled (see closed bug 41542 mentioned in comment 30).

According to Regina's comment 24 only workarounds will be possible?
> The "margin"-area is always transparent.... So margins can never
> have a background.

So the workaround from comment 16 should suffice since borders are no longer required
> A somewhat plausible workaround for this is to set the page margins to 0.00"
> and ... set spacing to contents to 0.79", 
> though the border will still be present. [no longer true in 5.4]
Comment 34 Lenge 2017-08-12 01:31:22 UTC
Yes, 5.4 can now "emulate" the desired behavior with the mentioned workaround:
1. All page Margins = 0
2. No borders
3. Spacing to Contents = <desired page margins>

While this is a big step towards resolving this issue, it has at least one major drawback (so IMHO the issue cannot be closed at this point):

When the workaround is applied, the horizontal and vertical paragraph rulers are moved and expanded to cover the entire page instead of only the text area. This is extremely ugly and affects all elements whose coordinates are based on the rulers (e. g. paragraph indent and tab markers), which are no longer in place when some "Spacing to Contents" is used instead of "Margins".

I'd propose to resolve this by ALWAYS aligning the rulers to the text space WITHOUT the internal padding (= "Spacing to Contents") - consistently for the page, text frames and any other places that might apply.

This will probably require testing with multi-column settings and might even affect compatibility with older documents, yet it is still the "cleanest" approach IMHO. In fact, the rulers should really have accounted for the padding in the first place, and maybe an according compatibility setting is enough to resolve any potential backwards compatibility issues.
Comment 35 Cor Nouws 2017-08-13 09:40:40 UTC
Closing with explanation of comment #33
Thanks Justin!

(In reply to Lenge from comment #34)

> When the workaround is applied, the horizontal and vertical paragraph rulers
> are moved and expanded to cover the entire page instead of only the text
> area.

Indeed - thanks for notifying. Please open a separate enhancement issue for that (and mention it here).

Cor
Comment 36 Lenge 2017-08-14 00:28:51 UTC
> (In reply to Lenge from comment #34)
> > When the workaround is applied, the horizontal and vertical paragraph rulers
> > are moved and expanded to cover the entire page instead of only the text
> > area.
> Indeed - thanks for notifying. Please open a separate enhancement issue for
> that (and mention it here).
Done, see bug 111779.
Comment 37 Yan Pas 2017-08-16 13:03:45 UTC
Current behavior is a workaround, but not solution. Should I create new ticket?
Comment 38 Regina Henschel 2017-08-16 13:41:03 UTC
This workaround was possible, because the ODF specification already allows this. 

The needed attribute draw:background-size for a true fix is only available for a page in Draw or Impress and a solution has to cover a proposal for a change of the ODF specification as well.

So yes please write an enhancement request and explain there, why the workaround is not sufficient. A rework of page styles in Writer is needed anyway, because of bug 103602, so we can add a remark there, to consider this enhancement request too.
Comment 39 Yan Pas 2017-08-16 18:20:10 UTC
I've read the specification. Well, it's quiet concise, but I haven't found mentions that background should be applied within margins. What if Libreoffice would not provide option to cover whole page and would cover whole page by default? Other suites (abiword, MS Word) already cover the whole page.
Comment 40 Regina Henschel 2017-08-17 00:32:00 UTC
Do you have examples from abiword or MS Word in ODF-format?
Comment 41 Yan Pas 2017-08-17 15:46:40 UTC
Created attachment 135625 [details]
docx with pink bg

I've tested popular office suites, here is what I've found:
1. MS Word (online and desktop) do not support ODT background
2. Abiword supports odt background and displays it with full pages
3. Calligra displays background the same way as LO
4. DOCX files created in MS Word or GDocs with page background are displayed in LibreOffice with background within margins. In other words not like in MS Word.

Here is docx example
Comment 42 Regina Henschel 2017-08-17 16:08:01 UTC
Currently the background color is in the "fo" namespace (which belongs to XSL) and most of the properties refer to CSS. And in CSS you have a box model. That result e.g. in:
margin left, border left, padding left, content, padding right, border right, margin right.
And in CSS the margin has to be always transparent.

I have some ideas how to get it to file, see bug 103602. Therefore I'm interested in the file from Abiword. It would be nice to get a file with solid color, a file with image, and a file with gradient or hatching, if Abiword is able to create such files. Can you attach such files? I would like to examine, if they write something special to file, or if they only display it different.
Comment 43 Yan Pas 2017-08-17 18:59:24 UTC
Created attachment 135628 [details]
abiword files

I've created both files in abiword. Libreoffice cannot open ODT with picture bg. But it opens odt with color bg. Margins are still white, seems like abiword displays them differently.

Despite ODT I guess we should display DOCX (and maybe other exotic formats too) correctly too. In other words LO should support drawing background on the whole paper. Seems like it's hard programming task if it is inherited from OpenOffice.
Comment 44 Lenge 2017-08-29 18:38:15 UTC
I'd like to request to keep this issue open until

(1) a true solution to the initial request becomes available (in terms of extending the ODF format to support full-page backgrounds including page margins), or at least

(2) the proposed workaround (replacing page margins with padding/"Spacing to Contents") no longer suffers from bug 111779. This is especially important as there seem to be controversial opinions on whether this should be fixed or not.

In the meantime, I wouldn't really consider this "resolved fixed". What do you think?
Comment 45 mailbox 2017-08-30 01:57:48 UTC
Agreed! It's not fixed until it's fixed.
Comment 46 Cor Nouws 2017-08-30 15:33:59 UTC
it's not at all uncommon in LibreOffice dev&QA that issues are marked as resolved with initial solutions, and that follow up issues are created and resolved for further improvements, better solutions.
So arguing if this one is fixed or not, is not really more than bike-shedding ;)
Comment 47 Lenge 2017-09-03 17:41:07 UTC
(In reply to Cor Nouws from comment #46)
> it's not at all uncommon in LibreOffice dev&QA that issues are marked as
> resolved with initial solutions, and that follow up issues are created and
> resolved for further improvements, better solutions.
Ok, here we go: Bug 112195
Comment 48 Mike Kaganski 2019-09-14 16:04:48 UTC
FTR: 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 49 Thomas Lendo 2019-09-14 20:31:41 UTC
(In reply to Mike Kaganski from comment #48)
For such reason I opened bug 122511 'Thicker border line than 9 pt or 5 cm'. The other See also bugs there are maybe important too.
Comment 50 Mike Kaganski 2019-09-14 21:40:32 UTC
(In reply to Thomas Lendo from comment #49)

No, that's different: you are proposing a new way of doing a desired effect; I'm taking about not breaking existing documents.
Comment 51 Fede 2020-11-24 12:47:02 UTC
So the solution to this "bug" has been breaking backward compatibility, disallowing previous behaviour, and making shadows weird if no border.

So borders and shadows refer to the text area, but background refers to the entire page. It makes no much sense to me (maybe because it breaks some documents I was using).

Just in case I have misunderstood something: is there currently a way to get a white margin, a coloured text area, and a projected shadow? If not, I'm not sure that SOLVED FIXED is the proper state for this issue.
Comment 52 Mike Kaganski 2020-11-24 13:01:33 UTC
(In reply to Fede from comment #51)

QED. Exactly what was discussed in comment 48.
Please File a bug report, with a keyword "regression", and put this bug to "See Also" in the new bug.

My own opinion is that we need a policy of automatic revert of any such change without a compatibility option and without an explicit ESC approval.
Comment 53 Regina Henschel 2020-11-24 14:02:49 UTC
This is indeed incomplete in regard to ODF 1.3. Therefor TDF has put it into the tender https://blog.documentfoundation.org/blog/2020/10/20/tender-to-finish-transition-of-libreoffice-to-odf-1-3-odf-1-3-delta-202010-01/

Hopefully we get an offer for it.
Comment 54 Timur 2020-11-24 19:15:18 UTC
Sorry, but I open again. Surely this is not status Fixed, because Fixed means specific commit,so it was more appropriate for WFM. 
But from comments it more looks like there is a workaround and not real solution.
Comment 55 Mike Kaganski 2020-11-24 19:26:06 UTC
(In reply to Timur from comment #54)

László Németh had implemented the change for tdf#112195 - https://git.libreoffice.org/core/+/f006b6339e20af6a3fbd60d97d21590d4ebf5021 - and then it was reported in release notes for this bug: https://wiki.documentfoundation.org/ReleaseNotes/6.3#Writer.
Comment 56 m_a_riosv 2021-06-21 20:43:52 UTC
*** Bug 142972 has been marked as a duplicate of this bug. ***
Comment 57 Stéphane Guillou (stragu) 2021-07-23 12:58:05 UTC
This has been fixed by Michael Stahl with the following commit:

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

Tested in:

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: cd2b5168e8ef1cb6e721bc5220421464ed723096
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-21_14:56:23
Calc: threaded