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.
- the .odt
- the resulting .pdf
- screen shot
Created attachment 41936 [details]
Created attachment 41937 [details]
LO screenshot with the .odt open
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
Something very similar has been a really long-standing request for "Upstream OOo":
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.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
3.5.0b2, Windows x86, the issue is still present.
Changing status to NEW as per the spambot instructions.
*** Bug 53331 has been marked as a duplicate of this bug. ***
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).
Nice trick, thx!
*** Bug 67301 has been marked as a duplicate of this bug. ***
*** Bug 79286 has been marked as a duplicate of this bug. ***
*** Bug 90167 has been marked as a duplicate of this bug. ***
*** Bug 93165 has been marked as a duplicate of this bug. ***
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
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. :)
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.
(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
+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
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).
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).
Migrating Whiteboard tags to Keywords: (needsDevEval)
(how can one ever find this bug when the component is UI :\ )
(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
@regina: Is this a limitation of ODF or is this just a bug in LO?
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.
(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) ?
(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.
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
Created attachment 127160 [details]
Document with the described workaround
(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).
(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.)
(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.
possibly related OASIS issue:
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]
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.
Closing with explanation of comment #33
(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
Indeed - thanks for notifying. Please open a separate enhancement issue for that (and mention it here).
> (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.
Current behavior is a workaround, but not solution. Should I create new ticket?
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.
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.
Do you have examples from abiword or MS Word in ODF-format?
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
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.
Created attachment 135628 [details]
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.
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?
Agreed! It's not fixed until it's fixed.
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 ;)
(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