Usually I have to keep a format with my documents. But when I a header/footer in writer it messes it up, and the content is sqeezed into a smaller area. So cumbersomely I have to compensate by decreasing the margins, which is impossible to do accurately because I can't know exactly how tall a margin is. (especially if I add a vertical line or such). The ability to put the header/footer in the margin would save me this mess. They are supposed to be in the margin anyway most of the time.
@cedric would you have a look at this and see if it makes sense ( I'm afraid I don't understand exactly the issue ) @Zsolt could you maybe supply a test document and/or screenshots to illustrate the problem more clearly here, thanks!
(In reply to comment #1) > @Zsolt could you maybe supply a test document and/or screenshots to illustrate > the problem more clearly here, thanks! Its specific to some documents. The problem is simply that the header essentially extends the margins, being in the margin. So the page text gets less space than intended.
@Zsolt: Please draw a little sketch illustrating your problem and describe more exactly what your problem is. Descriptions like "The problem is simply that the header essentially extends the margins" are completely useless, you should better give a precise description like "after ... I see in dialog ... that margin width has been increased from ... to ..." or similar. Please contribute a detailed step by step instruction how to reproduce your problem. I can't remember that I have seen something similar, but may be I don't understand all details of your problem..
Created attachment 45266 [details] Image showing the problem (In reply to comment #3) > @Zsolt: > Please draw a little sketch illustrating your problem and describe more exactly > what your problem is. Descriptions like "The problem is simply that the header > essentially extends the margins" are completely useless, you should better give > a precise description like "after ... I see in dialog ... that margin width has > been increased from ... to ..." or similar. > > Please contribute a detailed step by step instruction how to reproduce your > problem. I can't remember that I have seen something similar, but may be I > don't understand all details of your problem.. I don't understand why is it unclear. You add a header/footer and the content decreases from the desired size. Unlike MS Word where they're added to the margin and don't mess up the page format. Anyway, I attached an image explaining the problem.
The current behavior is intended (I think so), and I do not want to have that changed, even if other text processors do that in an other way. Our / my logic: The margin is the distance between contents and paper border. Header / Footer are parts of the (printed) document contents; to me it seems absolutely consequent that also the header has to respect the distance to the paper sheet border. There is no benefit if you add a heading without touching text body contents in the page, and the printer will cut away the heading ;-) I believe the current help text is misleading, I filed a report for that: Bug 35993 - WIKIHELP: Wrong description for Header / Footer place. I see that WONTFIX, but may be lots of users will protest here? @Zsolt: Thank you for your patience.
(In reply to comment #5) > The current behavior is intended (I think so), and I do not want to have that > changed, even if other text processors do that in an other way. > > Our / my logic: The margin is the distance between contents and paper border. > Header / Footer are parts of the (printed) document contents; to me it seems > absolutely consequent that also the header has to respect the distance to the > paper sheet border. > > There is no benefit if you add a heading without touching text body contents in > the page, and the printer will cut away the heading ;-) > > I believe the current help text is misleading, I filed a report for that: > Bug 35993 - WIKIHELP: Wrong description for Header / Footer place. > > I see that WONTFIX, but may be lots of users will protest here? > > @Zsolt: > Thank you for your patience. But this way you can't keep the document in the necessary format, because there is no way to determine the header/footer height. I had to write a document in a specific format, with rules for margins. When I added header in MS Word I was done, the margins were intact. But when I did this in writer I had to compensate by decreasing the margins by guessing to adhere to the rules, which is ridiculous. Its illogical, to do it this way. At least the user should be able exactly specify the height of the header/footer, and get some feedback of its height. On better would be if the header would automatically took the space form the MARGIN and not the content. It wouldn't be a problem, since writer could notify the same way as it does when one decreases the margins.
*** Bug 36853 has been marked as a duplicate of this bug. ***
I use this software for years, since OpenOffice time and I never liked the header and footer behavior, but with the time I got used. So, today, I decided to try to change this and report a bug. Then I arrived here and saw this bug is marked as WONTISSUE. Why? I understand that fix this will not be trivial, but I think the correct behavior of headers and footers is outside body area. LaTeX, as a good reference, works in this way.
I'd like that you reconsider your decision of marking this request as WONTFIX, based on my previous comment.
<http://wiki.documentfoundation.org/BugReport_Details#Particular_Versions>
@Rainer Bielefeld, Thanks for reopening this. It looks like a good conversation. I usually don't mind tinkering, so I have never cared about this issue. The convention you use, I agree is most logical assuming a margin is only used for the distance between the edge of the paper and where the printer begins printing. Unfortunately, someone who had market muscle implemented an illogical system that has warped our way of thinking. I wish your way of thinking would catch on. Until then, could there be a macro type fix? Example, add a button on the side of the "Margin" text under the "Page" tab called "MLA/College style" or something. Clicking it would open a window with: A. Page Margin size input boxes, B. Header/Footer Margin size input boxes, and C. Header/Footer Distance from top and bottom of page input boxes. Lets say the user puts in: A. all 1" margins for the page, B. 1" header/footer size, and C. .5" from top and bottom of page. The macro would automatically set the values appropriately: A. Page's top and bottom Margin input boxes would be set to .5" (value is pulled from "distance from page edge) (other values left as is) B. Header/Footer's size would be set to 1". My thoughts are, instead of rewriting how the program already works, other peoples method of thinking can be accommodated by simply giving them a tool to automatically convert whats in their head to what should be inputted into the program. Hope this made some sense. Thanks for making Libre Office a great program. Matthew B.
I am sorry, looks like this issue was resolved with "dynamic spacing" button. Am I correct?
I have tried enabling dynamic spacing with a header already in place and before inserting a header, and neither time did it solve the aforementioned problem. As a student who needs documents to have exactly 1" margins (from top of document to body text - does NOT include headers, however much or little sense that may make; it's the rule). Can someone please either: a) explain to me how to use the dynamic spacing option to resolve this issue (it's not in the help section) or b) revisit this issue? Thank you.
(In reply to comment #12) > I am sorry, looks like this issue was resolved with "dynamic spacing" button. > Am I correct? Sorry, but ”dynamic spacing” is a completely different issue. @Peter: You did right to reopen this issue. @All: Plese note: This is an enhancement request, not a bug report. You can think that this request is not useful. Mostly, it is just a matter of taste if one prefers the current behaviour or if one prefers the requested behaviour. But nevertheless this all does not make this feature request invalid, so please don’t close it so easily. IMHO the best thing to do is what has just begun in this report -- to discuss the issue and to consider all pros and cons. Even better would be a discussion with UI and/or page layout experts. If they say that the current behaviour is clearly the better one, we can set this report to RESOLVED/WONTFIX. But until that, the user is free to request this enhancement/change, and IMHO we should not close the request.
> @Peter: > You did right to reopen this issue. > Thank you both for considering it worth discussing ;-) > @All: > Plese note: This is an enhancement request, not a bug report. You can think > that this request is not useful. Mostly, it is just a matter of taste if one > prefers the current behaviour or if one prefers the requested behaviour. But > nevertheless this all does not make this feature request invalid, so please > don’t close it so easily. > IMHO this can lead to a new option via Format -> Page, on the Page tab rather than individually on Header and Footer tabs. A radio button with some label like "header/footer location:" with "page margins"/"text body" options will surely do a nice job. I agree it's an enhancement request, now that I see people are actually supporting/using the current behavior I begin to think it's only a matter of taste and habits. I am still supporting my version though, and I have a solid use case for this: imagine writing a long document, and *after* you finish it you realize you forgot to add some header => this will be messing up a decent amount of page formatting at least. My $0.02 are either for an option or placement into margin. Many thanks for your attention, Victor
Should be NEW not REOPENED.
*** Bug 99828 has been marked as a duplicate of this bug. ***
(In reply to Zsolt from comment #6) > But when I did this in > writer I had to compensate by decreasing the margins by guessing to adhere > to the rules, which is ridiculous. Its illogical, to do it this way. Of course, it is sometimes extra work. In general one starts setting general lay out (page and other styles) before finishing text flow details. And if header/footers are added later on, the size is know from the settings (marginal exceptions as borders maybe aside). Since it's my expectation that changing the current behaviour is a major^2 effort (with consequences in all areas of the software) I would not expect too much of this. (Of course apart from why he choice for the situation as is, has been made.) Just saying to manage expectations.
It's hard to think that this is an enhancement request when it causes some serious interop issues that prevent LibreOffice from being used in professional settings where formatting is everything (where the content of a document can and will be entirely ignored absent 100% compliance to specific formatting requirements). Although we may all agree that it's unfortunate that MSO sets some of these standards, the reality is that, at least in my profession, this is a serious hindrance of ever relying on LibreOffice for legal work in my jurisdiction. Because I am personally impacted by this bug I'll refrain from changing the status but I hope that others who are unbiased can at least consider my point above. I'd suggest somewhere between normal - medium to major - high is appropriate considering really basic documents can be impacted with interop issues.
(In reply to Joel Madero from comment #19) > It's hard to think that this is an enhancement request when it causes some > serious interop issues Are we sure that this is the case? Normally the margins are just exported fine. Measured/set different, but the visual result is the same. Or are there reproducible cases that I miss?
(In reply to Cor Nouws from comment #20) > (In reply to Joel Madero from comment #19) > > It's hard to think that this is an enhancement request when it causes some > > serious interop issues > > Are we sure that this is the case? Normally the margins are just exported > fine. Measured/set different, but the visual result is the same. > Or are there reproducible cases that I miss? All I know is that if you check the documents in MS Word it shows different margins. When submitting digital files (vs. print), someone who is a stickler for formatting (lots of people in my profession at least) would just check the margins, see that it's not set to what they demanded, and proceed to refuse to read the content.....yes, this stuff does in fact happen.
(In reply to Cor Nouws from comment #20) > (In reply to Joel Madero from comment #19) > > It's hard to think that this is an enhancement request when it causes some > > serious interop issues > > Are we sure that this is the case? Normally the margins are just exported > fine. Measured/set different, but the visual result is the same. > Or are there reproducible cases that I miss? How can this not be an issue when you can't set the position of the header, you can just approximate by hand. The margins will be of course totally different, since the header is in the body.
> > How can this not be an issue when you can't set the position of the header, > you can just approximate by hand. > The margins will be of course totally different, since the header is in the > body. To be fair I didn't have to estimate at all. When I open the document in the duplicate bug that I reported it automatically opened and showed different margins (1.39" on top and bottom instead of 1") so the computer did the work for me.
(In reply to Joel Madero from comment #21) > .....yes, this stuff does in fact > happen. Your bug 99639 could not be reproduced by various people. (And in general it is behaviour that I do not recognize in ~12 years..)
(In reply to Zsolt from comment #22) > How can this not be an issue when you can't set the position of the header, > you can just approximate by hand. What exactly do you mean? This confuses me, since as far as I know, Format > Page, tabs Page / Header / Footer let you set very specific dimensions.
(In reply to Cor Nouws from comment #25) > What exactly do you mean? This confuses me, since as far as I know, Format > > Page, tabs Page / Header / Footer let you set very specific dimensions. If your document has to conform to given parameters (incl. margins), those parameters will be given based on Word's behavior, because that's what is used widely. If you're given, let's say, 2.5 cm margins to keep to, and you don't have Word, you can't know the exact number you have to use in Writer. In the image attached by Zsolt, 1st is Writer setting, 3rd is Word's setting, and 2nd shows the missing information(/setting) in Writer. This is also what Joel experienced in bug 99639. While technically there might not have been a bug in the conversion, but a 2.5 cm margin in Writer and a 2.5 cm margin in Word resulted in ~0.75 pages of difference in 10 pages. And if you have set limits to follow, that's a huge difference.
(In reply to Cor Nouws from comment #25) > (In reply to Zsolt from comment #22) > > > How can this not be an issue when you can't set the position of the header, > > you can just approximate by hand. > > What exactly do you mean? This confuses me, since as far as I know, Format > > Page, tabs Page / Header / Footer let you set very specific dimensions. It seems to be better than it used to be. Though you still have to muck around in the configuration to get an equal result. Subtract the header height from the margin and re-set the margin. Disable dynamic height, set the margin of the header to zero, or subtract that also.
(In reply to Aron Budea from comment #26) > If your document has to conform to given parameters (incl. margins), those > parameters will be given based on Word's behavior, because that's what is > used widely. If you're given, let's say, 2.5 cm margins to keep to, and you > don't have Word, you can't know the exact number you have to use in Writer. > In the image attached by Zsolt, 1st is Writer setting, 3rd is Word's > setting, and 2nd shows the missing information(/setting) in Writer. If you just set 2.5 margin in Word, you have the same result as when you just set 2.5 margin in Writer. When header/footers are involved, you need to follow the design, that should mention header/footers height and distance. The only thing that differs is where/how you set them in Writer and in Word. > This is also what Joel experienced in bug 99639. While technically there > might not have been a bug in the conversion, but a 2.5 cm margin in Writer > and a 2.5 cm margin in Word resulted in ~0.75 pages of difference in 10 > pages. And if you have set limits to follow, that's a huge difference. That problem has not been confirmed. We do not know what went wrong there. I will attach two documents: - new DOCX document from Word with (default) margins - new DOCX from Writer with (default) margins Both appear the same in Word and in Writer.
Created attachment 125084 [details] new Word doc with default page settings
Created attachment 125085 [details] new docx from Writer with default page margins
So as far as I understand this, what changing the current behaviour would do, is change the way a user sets the page/header/footer properties, cause a lot of work, probably bugs in unexpected areas (since all code works together). When user workflow can be improved, clarified: fine. When specific files are rendered wrong: improving the import of those is important too.
(In reply to Cor Nouws from comment #31) > So as far as I understand this, what changing the current behaviour would > do, is change the way a user sets the page/header/footer properties, cause a > lot of work, probably bugs in unexpected areas (since all code works > together). > When user workflow can be improved, clarified: fine. > When specific files are rendered wrong: improving the import of those is > important too. I encountered this problem after writing an incredibly important assignment that had a 10 page max limit. I wrote the entire thing in LibreOffice and I was at 1 line under 10 pages. I Saved as a docx and booted into Windows to verify that the document looked okay (it literally was only a single size font, one type face, with some italics and bold) so I made the horrible assumption of assuming that things would be fine. I booted into Windows, opened the document in 2010, and checked the margins in MSO. The margins no longer showed 1" which was the *requirement*, instead they showed 1.39" on top and bottom which was a huge problem. This was a time sensitive assignment that had to be turned in as a digital file with incredibly specific instructions (simple but specific) so the person who was reading it would *likely* open the document and immediately check the margins - only to see 1.39" on top and bottom. This bug almost caused me a tremendous amount of pain. The fact that we're still arguing over whether it is a bug or not baffles me.
> > That problem has not been confirmed. We do not know what went wrong there. > I will attach two documents: > - new DOCX document from Word with (default) margins > - new DOCX from Writer with (default) margins > Both appear the same in Word and in Writer. Please just check the document in my dupe. In writer it shows 1" all the way around, in both MSO 2010 and 2013 it shows a custom margin with 1" on left and right, 1.39" on top and bottom. It's pretty straight forward to confirm (I just did it on 3 machines).
> > Are we sure that this is the case? Normally the margins are just exported > fine. Measured/set different, but the visual result is the same. > Or are there reproducible cases that I miss? One more annoying rant here (sorry but this really almost cost me big and I want to be crystal clear in my explanation as to why it is in fact a serious bug). If you have an assignment (court assignment, thesis, dissertation, school final, etc...) that has specific requirements that say 1" margins all the way around with a max page limit (let's just say 10 pages). You write the entire thing in LibreOffice and you see that you've hit your max limit and margins are 1" as needed. The *best case* scenario is that the end reviewer opens the document and does not check the margins in Microsoft Office. This way it *artificially* looks like you've met the requirements that they have given. BUT even in this case what has actually happened is that you're about 0.75 pages short, so you've been lead to believe that you're at the page limit and thus can't add additional *critical information* when in fact you haven't. To verify this, in Microsoft Office just set the margins to 1" (as the instructions *required*) and you'll notice that now the 10 page document is 9.25 pages. So if you had followed the instructions *exactly* (using the standards that every professional institution expects) you would have been allowed to write almost 10% more content - in my case, critical content, that I thought I just didn't have the space to include. The *worst* case scenario is that the reviewer quickly checks the margins in Microsoft Office, sees that you failed to follow instructions, and refuses to read the content. This is all confirmed, by multiple people.
(In reply to Joel Madero from comment #34) > If you have an assignment (court assignment, thesis, dissertation, school > final, etc...) that has specific requirements that say 1" margins all the > way around with a max page limit (let's just say 10 pages). You write the > entire thing in LibreOffice and you see that you've hit your max limit and > margins are 1" as needed. If you just set 2.5 margin in Word, you have the same result as when you just set 2.5 margin in Writer. When header/footers are involved, you need to follow the design, that should mention header/footers height and distance. The only thing that differs is where/how you set them in Writer and in Word. I think this is a good topic for the most useful stuff to know when switching from Word to Writer.
(In reply to Joel Madero from comment #32) > This bug almost caused me a tremendous amount of pain. The fact that we're > still arguing over whether it is a bug or not baffles me. Bug 99639 could not be reproduced and someone closed as WorksForMe..
(In reply to Cor Nouws from comment #36) > (In reply to Joel Madero from comment #32) > > > This bug almost caused me a tremendous amount of pain. The fact that we're > > still arguing over whether it is a bug or not baffles me. > > Bug 99639 could not be reproduced and someone closed as WorksForMe.. That's simply not true. Bug 99639 was reproduced and explained by Aron. The issue is that when in Word, if you set the margins to the *required* settings per professional specifications, the document becomes 0.75 pages shorter. To repro: 1. Open the document in Word; 2. Open the page margins dialog Observed: Despite Writer saying it's 1" around each side, Word (which dictates the professional standard in this case) shows 1.39" on top and bottom 3. Set the margins to the *specified* margin (1" all the way around) Observed: The document is now 0.75 pages short of the limit which cuts out substantial space (nearly 10%). This is *only* visible if the person writing the document has Word to actually check. So if the idea is LibreOffice can replace Word entirely and a user can avoid having to double check work in Word - the is not present. If this issue is not a bug, I don't know what is....
> If this issue is not a bug, I don't know what is.... Just one more clarification here. So my point is that if I did not have Word, I would have just submitted the document *as is*. One of two situations would have happened: 1) The reviewer would have checked the margins and seen 1.39" around and *refused to read the content*, resulting in a VERY bad situation; 2) The reviewer would have seen 1.39" on top and bottom, changed these to 1" on top and bottom (as the professional standards *required*) and would have seen that I was nearly 10% short of the page limit. Then the reviewer undoubtedly would have noticed some issues that I could have written about and been upset that I left 10% of the page limit unwritten. If the idea is "LibreOffice can kind of work for you if you have MS Office to verify that professional standards are being applied" then sure, this works. I can always open a document in Word to double check that my document is being treated identically in Word and Writer. It's a PITA and I'm personally unlikely to do it (why wouldn't I just use Word to begin with?) If the idea is that LibreOffice can *replace* Microsoft Office and at least in many basic situations (a writer document with a single type face, one size font, that has footers and headers IMHO meets this) a user *need not fear* that a Word user would observe something inconsistent with LibreOffice - then LibreOffice is falling short of this goal. I'm not dictating that someone fix it (of course a volunteer would have to opt to do that), I'm just growing increasingly frustrated that I'm getting push back that this is a bug.
(In reply to Joel Madero from comment #37) > > That's simply not true. Bug 99639 was reproduced and explained by Aron. The > issue is that when in Word, if you set the margins to the *required* > settings per professional specifications, the document becomes 0.75 pages > shorter. Are you sure you're not mixing issues Joel? I've added a extra comment in https://bugs.documentfoundation.org/show_bug.cgi?id=99639#c14
I'll add explanation why is it so important. Some standards around the world specifies exact margin between edges and text body, while headers and footers have own rules. 1 mm of the standard makes document invalid. Even adding page number would break margins making document invalid.
Document processor developers are free to define the "coordinate system" for header/footer relative to text body or page margins. BUT, this convention should be clear so that users can appropriately design their page lay-out. It becomes crucial in thes current context of document exchange between platforms (with different fonts, therefore change in character sizes, width and height), locales and text processing applications. When the conventions for body/header/footer is known and defined, the conversion modules should recompute the placement of these areas in the target "coordinate system". Some may object that OASIS (or other coordinating body) did not foresee the problem and that the ODF does not contain elements to cope with this issue. This a very serious shortcoming impeding "safe" document exchange. Independently from visual fidelity to author intent, it is not acceptable to confer a standard role to a commercial proprietary application (even if it is the predominant one in the world) since its specifications may change without notice in unexpected areas and because some people made the deliberate choice not to use it. Also, the abrupt change of layout cause by this bug can have an economic impact: if total number of pages increases, this may mean another section (don't know if it the right word: a new large sheet folded into a 16-, 32- or 64-page section) to add to a printed book, i.e. more money to spend to manufacture the book. If the nuber decreases, we are faced with a non-optimal use of paper. IMHO, this a very serious bug which should be addressed quickly because it threatens the position of LO as a challenger of ubiquitous M$O and prevents presently a full replacement of said M$O by LO.
*** Bug 99639 has been marked as a duplicate of this bug. ***
This is an interoperability issue, so not something UX should have to deal with. I would assume this an issue of LO focused on the ODF's view of how headers/footers are done and this doesnt translate correctly when opening in MSO. @Regina: any thoughts?
(In reply to Yousuf Philips (jay) from comment #43) > This is an interoperability issue, so not something UX should have to deal > with. I would assume this an issue of LO focused on the ODF's view of how > headers/footers are done and this doesnt translate correctly when opening in > MSO. Tests in both this issue and duplicate (..) 99639 show that this assumption is not correct. In any case not in the circumstances from these tests.
I think, that some of the comments confuse page design with the technical means to get this design. In Word you set the distance between text block and edge and the distance between header and edge, the header height is calculated. In LibreOffice you set the distance between header and edge and the header height, and the distance between text block and edge is calculated. But that are only technical differences for making a page design with margin, header and text block. It is simple math to convert one setting to the other. I see no interoperability problem. LibreOffice changes the settings on import and export from and to docx to get the same page design as in Word. And the other way round, Word does the same when getting an odt-file. (In reply to Joel Madero from comment #38) If a student is not sure, that the reviewer can distinguish between page design and technical settings, the student should ask for a document template, or the student makes a dummy document with LibreOffice and shows it to the reviewer. (In reply to regs from comment #40) > Some standards around the world specifies exact margin between edges and > text body, while headers and footers have own rules. 1 mm of the standard > makes document invalid. Even adding page number would break margins making > document invalid. That can be achieved by setting fixed header height in LibreOffice. (In reply to Yousuf Philips (jay) from comment #43) ODF uses the common block element model of margin-border-padding-content as used in XSL and CSS. In my understanding of the typographical terms, the "content" is that, what is named "type area" in typography, but I might be wrong. A running head is inside the type area. Ideally users first design their "master pages" aka page styles and fill the document with content afterwards. But reality is different. Users add a header after they had written the content, and their tweaked page breaks will be disturbed. For the cases, where a user uses the menu item "Header and Footer" and does not make the settings directly in the page style, I can think of a dialog, where the user is asked, whether the header should be placed into the area of the former margin, or whether the page text area should be reduced to get room for the header below the margin. That would only require a new dialog for calculating the needed settings, but no further changes in the code.
Created attachment 133853 [details] Screenshot of Footer at page with yellow background color I agree to the idea that header/footer should not be part of text body. One reason is that the page background filling should not (always) be extended to the header and footer and to the space between header/footer and content area. See attached showing the yellow page background filling and showing the footer area surrounded by red color.
(In reply to Regina Henschel from comment #45) > I see no interoperability problem. LibreOffice changes the settings on > import and export from and to docx to get the same page design as in Word. > And the other way round, Word does the same when getting an odt-file. yep..
A problem related to what is discussed here is that mentioned in Bug 111325. Because a header is added when inserting a watermark, the space of the text body decreases slightly, but it can have consequences in the design layout. I think that by default LO should insert headers/footers in the margins, however, allowing the user to choose to insert the headers/footers in the margins or as part of the text body would give more control of the document layout. Cheers
I stumbled across the same issue when I was writing my diploma thesis. Oftentimes its required bz universities to have a certain margin between border and body text with the header and footer not defined. A check mark option to include headers into the margin or not would help fix this problem. (I know its not as easy as that sounds)
comment #44 and comment #47 show there is no interoperability issue. So I close this issue as WFM. If people have suggestions on how to help users for the apparently sometimes occurring confusion, please do file an issue for that. And be so kind to refer to this one. Thanks, Cor
6.1.1.2 NOT FIXED! When i set page top margin to 1 cm, then add a header, top margin gets ignored. All content moves down. Header is always located within content margin, but shouldn't.
Per QA guidelines and Comment 16, do NOT set status to REOPENED. This is a developer only tag. This issue should be closed unless we can get clear, step-by-step instruction to reproduce the issue. Writer behaving differently than Word is NOT a bug and there is no import or export issue here. If you want to change the behavior of Writer, please give step-by-step instructions with expected behavior and current behavior. This would be an enhancement request. https://wiki.documentfoundation.org/QA/BugReport#Good_Reports
Full steps to reproduce. 1. Open Writer. 2. Type something. 3. Open page setup settings. 4. Set page margins to, say 1 cm for every side. 5. Now try to add header. 6. Content moves down, but should keep staying at 1 cm per standard. It's not about acting different, it's about acting wrong, disrespecting different documentation standards all around the world. MS Office and all other alternatives do it right way.
The issues here: 1. Terminological (and coordinate system) problem: what Writer calls "margin" is not what Word calls "margin"; the latter uses that term for what is margins + headings (roughly) in Writer. this is also ... 2. Computational problem: when I mentioned "roughly", I e.g. didn't consider borders width; and the latter is usually expressed in different units compared to the rest; so it's not easy to calculate the correct elements sizes to get exactly what is expressed in the other coordinate system, even when one understands the idea. 3. Missing functionality problem: although it's true that Writer system can do things Word can't (easily), the opposite is also true: e.g., in Writer, it's difficult to make headers to grow from page body upwards, i.e. when it's single-line, it starts just as close to page body as when it's 3 lines high. 4. Habit/least surprise principle problem: when users decide to add a header/footer to a document with content, users expect (out of habit, or because it just seems logical) that the pages will keep their current content, and the added headers/footers would not reduce the page body area. 5. Formatting problem: see comment 46. Those are actually mostly *different* problems; and the problem 4, which has possibly the largest impact, is likely the easiest to fix just by making the algorithm adding header/footer to recalculate margins (as final part of comment 45 suggests). That would partly address also problem 2, which might be further addressed e.g. by the complex "page layout" dialog, which would allow the two coordinates variants simultaneously, and do all the recalculations itself.
From Comment #54: "4. Habit/least surprise principle problem: when users decide to add a header/footer to a document with content, users expect (out of habit, or because it just seems logical) that the pages will keep their current content, and the added headers/footers would not reduce the page body area." I am NOT coming from MS Word. Nonetheless the mentioned expectation doesn't look "just funny" to me. However, I would NOT judge it to be "LOGICAL". Reasons: To get it consistent under the given rationale (unchanged content of the page's textbody area) the changed behaviour to insert a newly enabled header and additionally the height of space (distance from text body) into the area previously forming the visible margin WOULD REQUIRE to also shift the top of the header's area uppwards if an additional line or paragraph was inserted or the fontsize of the header was increased and 'AutoFit height' was enabled. The change would also require to specify the substituting behaviour in a way "expected out of habit or {seeming} logical" for the case that the margin not is high enough to take the insertion. (Of course, we need at the same time to regard thze footers.)
(In reply to Wolfgang Jäger from comment #55) > I am NOT coming from MS Word. Nonetheless the mentioned expectation doesn't > look "just funny" to me. However, I would NOT judge it to be "LOGICAL". > > Reasons: > To get it consistent under the given rationale (unchanged content of the > page's textbody area) the changed behaviour to insert a newly enabled header > and additionally the height of space (distance from text body) into the area > previously forming the visible margin WOULD REQUIRE to also shift the top of > the header's area uppwards if an additional line or paragraph was inserted > or the fontsize of the header was increased and 'AutoFit height' was > enabled. > > The change would also require to specify the substituting behaviour in a way > "expected out of habit or {seeming} logical" for the case that the margin > not is high enough to take the insertion. > > (Of course, we need at the same time to regard thze footers.) Oh, I wrote that, and I still have questions. 1. Do you suppose that I meant something "funny" when wrote problem 4? It's unclear to me from your text. Do you suppose that what I wrote to have the largest impact to be dismissible? 2. I don't understand what is your *position* that you give a rationale below ("it does not look FUNNY" ... "I would NOT judge it to be "LOGICAL" confuses me). 3. And the last thing: the given rationale absolutizes the approach; while e.g. Word also may decrease page body if headers/footers grow; it's just the first moment of insertion that actually has the psychological expectation that isn't met in Writer. So we may actually do that without changing also the process of growth of headers.
Hi Mike, (In reply to Mike Kaganski from comment #54) > 4. Habit/least surprise principle problem: when users decide to add a > header/footer to a document with content, users expect (out of habit, or > because it just seems logical) that the pages will keep their current > content, and the added headers/footers would not reduce the page body area. Might be me, but I can't remember ever having been surprised by the fact that adding header/footers would cause repagination. Moreover, the rather vocal expressions of different ideas are not at all convincing. It is behavior that you see right there in front of you. Easy to adjust - if needed. And imagine margins set for printing purposes - if needed for anything, it's needed for that, not for what you do on the screen.
Why marking not a bug, when all necessary info was provided?
Full steps to reproduce. 1. Open Writer. 2. Type something. 3. Open page setup settings. 4. Set page margins to, say 1 cm for every side. 5. Now try to add header. 6. Content moves down, but should keep staying at 1 cm per standard.
> And imagine margins set for printing purposes - if needed for anything, it's > needed for that, not for what you do on the screen. Exactly what this bug is about. If you add "header" all your content moves away. So if you needed for that, it's gone. So margins do not serve purpose.
(In reply to regs from comment #58) > Why marking not a bug, when all necessary info was provided? You were so kind to give info on your opinion. I understand that there are situations where this causes you extra work, which is not nice. On the other hand there are the situations where the current behavior is just great logic. So it won't surprise you that in fact there opinions and ideas regularly that are not reflected in the software. I'm sorry for you that in this case it is not on your side.
But, it's not about opinions. It's about noncompliance to standards. Where all other office applications doing it the right way and libre doing it the wrong way.
(In reply to Mike Kaganski from comment #56) > (In reply to Wolfgang Jäger from comment #55) > > I am NOT coming from MS Word. Nonetheless the mentioned expectation doesn't > > look "just funny" to me. However, I would NOT judge it to be "LOGICAL". > > > > Reasons: > > To get it consistent under the given rationale (unchanged content of the > > page's textbody area) the changed behaviour to insert a newly enabled header > > and additionally the height of space (distance from text body) into the area > > previously forming the visible margin WOULD REQUIRE to also shift the top of > > the header's area uppwards if an additional line or paragraph was inserted > > or the fontsize of the header was increased and 'AutoFit height' was > > enabled. > > > > The change would also require to specify the substituting behaviour in a way > > "expected out of habit or {seeming} logical" for the case that the margin > > not is high enough to take the insertion. > > > > (Of course, we need at the same time to regard the footers.) This is still my opinion. I judge it to be well considered, and -at least- not just arguing for "the wrong way" as some contributors here seem to see it. How any other application does it or will do it 10 years from now isn't on my screen. > > Oh, I wrote that, and I still have questions. > > 1. Do you suppose that I meant something "funny" when wrote problem 4? It's > unclear to me from your text. Do you suppose that what I wrote to have the > largest impact to be dismissible? No. My words "not just funny" were expected to be understood as "deserving serious considerations". I never read anything posted by you that looked "funny" to me. Sorry for my poor English! Extremely sorry for any misunderstanding induced by my "funny wording"! > > 2. I don't understand what is your *position* that you give a rationale > below ("it does not look FUNNY" ... "I would NOT judge it to be "LOGICAL" > confuses me). > That's hard to understand for me. > 3. And the last thing: the given rationale absolutizes the approach; while > e.g. Word also may decrease page body if headers/footers grow; it's just the > first moment of insertion that actually has the psychological expectation > that isn't met in Writer. So we may actually do that without changing also > the process of growth of headers. The fundamental distinction between the original insertion of a header/footer and its later changes in height with respect to the interpretation of the term "margin" basically under discussion here (imo), I cannot accept under my understanding of what's logical. Also with this respect I won't figure the warrior, of course. Even inside mathematiocs it's disputed what's a proof, now and then.
(In reply to Wolfgang Jäger from comment #63) > > 2. I don't understand what is your *position* that you give a rationale > > below ("it does not look FUNNY" ... "I would NOT judge it to be "LOGICAL" > > confuses me). > > > That's hard to understand for me. :-) Oh, it's always a problem when two non-native-English speakers try to express themselves to each other ;-) so I'm also sorry for being stupid there. What I wanted to express is that I didn't understand your position: slightly simplifying, your words "it does not look FUNNY" seemed somewhat defending those who want to change the status quo, while "I would NOT judge it to be "LOGICAL"" seemed to be against that request. So I wanted to understand what your actual position was. Wrt the last part: I believe that the discussion here is mainly about the initial act of inserting headers/footers, as opposed to later modification of its contents (and subsequent change of page body space). These two, being of course connected, are not necessarily have the same psychological expectations. E.g., user could expect page body height to remain unchanged when inserting a default (=1-line) header, when margins are quite large; but it's not true that users would (have reasons to) expect page body to remain intact when they expand header arbitrarily, possibly exceeding remaining margin height. I don't want to say that fixing one aspect of multiple possible issues here is a universally satisfying solution; just that it would cover the most prominent source of misunderstanding. Here I don't tell about changing ODF or something, just about creating a UI to allow the one-time insertion operation to optionally simultaneously decrease margins to keep page body size. Some people here even keep thinking that they are talking about "conformance to standards", without understanding that there's no universal standards here, and e.g. current implementation strictly conforms to ISO ODF standard, which was by the way created with Microsoft participation in the OASIS committee :-).
(In reply to regs from comment #58) > Why marking not a bug, when all necessary info was provided? Nobody claimed a lack of information (as far as I can see). (In reply to regs from comment #59) > 6. Content moves down, but should keep staying at 1 cm per standard. Nobody missed reproducibility. Just your statement under "6." is not accepted by everybody. (Myself among those who reject it.) (In reply to regs from comment #62) > But, it's not about opinions. It's about noncompliance to standards. Where all > other office applications doing it the right way and libre doing it the wrong > way. It' s not about opinions? You definitely know what's right and what's wrong? What standards are you talking of? Who (what institution) approved them? In what way did you refute my hint concerning a text-body-margin not wide enough to take a header and its distance from the body? How to handle this case? As MS Word does? I don't know how it does. If "all the other office applications" should be entitled to define their "as-is" standards to also obligate LibO (and its complete family!) I would need to learn anew what a standard should be. Changing the behaviour of LibreOffice Writer in a way trying to "fix this bug" would also cause incompatibilities with Apache OpenOffice and othe descendants from the common roots.
I'm talking about documentation standards, not about file format standards. Our GOST have different standards for different type of documents. Standard document is having 1 cm margin from both top and bottom. 1 mm off the standard and document is invalid. But it is just impossible to maintain margins with Writer.
(In reply to regs from comment #66) While being a sysadmin, and then a MEP engineer at my former place (a project institute), I successfully created GOST-compliant (СПДС/ЕСКД) documents all the time (since 2007 iirc) when we used OOo/LO exclusively ;-)
Sitting and calculating paddings, line spacings and line heights is not really an option for an average user.
(In reply to regs from comment #68) Your argumentation is totally irrelevant (off-topic) here. You don't talk about "standards compliance", although claim to do so; what you are talking about is how easy it is for an abstract "average user" to create a setup suitable for a given (national) documentation standard. And that problem is orthogonal to what is discussed here, because for a given (national) documentation standard, it's enough for a official body to prepare suitable templates. That's what usually done by multiple bodies (often only for Word; but that doesn't change the idea: the documentation standards are really often make it difficult for an "average user" to create a compliant document using *any* suite, and the bodies have to provide pre-made templates to make users' lives easier). In some specific cases, some template may happen to be easier for someone to create using one software than the other... but please don't continue this unrelated discussion here.
(In reply to regs from comment #68) > Sitting and calculating paddings, line spacings and line heights is not > really an option for an average user. True. Is that still the same as when I reported the problem? It's ridiculous that I essentially have to trial and error by hand how much the height changes and compensate by if I add a horizontal line, or whatever. It wouldn't matter much if the height was consistent. It'd be still a nuisance though to have to subtract from the margin by hand.
We shouldn't operate with terms like "ridiculous" here. This in specific not if we didn't take te time to read the complete discussion. For my part I will forbear to tell you what I find ridiculous regarding this topic. For participants interested in a kind of workaround: https://ask.libreoffice.org/en/question/137961/header-and-footer-needed-outside-the-page-margin/ I posted a raw piece of user code there. You can refine/enhance it to your needs.
Such a long-standing issue with many interested users should be either kept open or closed only with proper explanation that would help avoid discussion (which wasn't done here).
(In reply to Timur from comment #72) > Such a long-standing issue with many interested users should be either kept > open or closed only with proper explanation that would help avoid > discussion (which wasn't done here). To me that looks as an underestimation of the hours that I've spent in this issue; testing, explaining, examples :)
Created attachment 149365 [details] Distance Header To Page Margin Is Shown On Ruler In Writer But let me add one more comment... (In reply to regs from comment #68) > Sitting and calculating paddings, line spacings and line heights is not > really an option for an average user. I do user support regularly in various roles and situations for OpenOffice/LibreOffice since 2004. Don't remember I ever had one complaining user who was unable to handle it. (In reply to regs from comment #66) > I'm talking about documentation standards, not about file format standards. > Our GOST have different standards for different type of documents. Standard > document is having 1 cm margin from both top and bottom. 1 mm off the > standard and document is invalid. But it is just impossible to maintain > margins with Writer. Are you sure you really tried how LibreOffice supports the users? The attachment shows that the metrics are there right in your face on the ruler. If it helps, I'm not at all against extending the information in the dialog Page Style, tab Footer and Header to show/mention that distance too, of course.
(In reply to Cor Nouws from comment #74) > If it helps, I'm not at all against extending the information in the dialog > Page Style, tab Footer and Header to show/mention that distance too, of > course. Maybe one of the people here that really need more info, more than what already is shown in the UI, can make a good proposal for the widgets on that tabs Header/Footer of the page style, and describe the desired behavior? If so, please create a new issue for an enhancement, and mention the number here. Thanks :)
Just my two cents, as this hits me every time I teach students how to style pages. So I'd plead for reconsidering this feature request. 1. I understand that the page margins in LO are counted similar as if they were print margins. The math is easy to follow and fairly easy to understand. 2. I can do the math to make it behave right (it's really easy, unless you need multiline content). 3. If I'd take something as a standard (or maybe better wording would be reference implementation/behaviour) it would definitely not be Word, but (La)TeX -- and well, in (La)TeX, page margins are all the way to text body, i.e. header/footer is inside the margins (add \usepackage[left=2cm,right=2cm,top=2cm,bottom=2cm]{geometry} to preamble and see the result). 4. For most usecases (all *my* usecases) this could be solved by: a) enabling Dynamic spacing by default (companion to autofit height) b) automatically recounting margin when header/footer gets inserted/changed, the math is easy, so it shouldn't be hard to implement (even if you add rules, pt can be converted to cm/in as needed), there could even be a tick somewhere to enable/disable this behaviour (probably in Writer settings, as one user would want it to behave same for all his documents). c) *or* enabling (empty) header/footer with reasonable margin + header/footer height/spacing settings by default on basic page styles (i.e. no unexpected change to text body when adding header/footer, because you would actually only add content to it) 5. Somewhat harder would probably be growing header (upwards -- in UI I would expect a tick (probably radiobutton) called Dynamic margin that would also untick Dynamic spacing and vice versa), not sure though if that would comply with ODT standards...
I do not understand why these has continued for so long without a solution, is it really that difficult to create a button that sets the margins as how it is asked practically everywhere? The standards will simply not change because a few Open Source paladins complain, if Libre Office wants to be a viable alternative to other Office Suites it should adapt to them, or at least give their users an easy way to do so.
It would be nice if someone would make an overview document of header/footer margins in all major suites (with screenshots), pointing to all arguments from this bug.
Possibly useful here: an overview of the sizes in Writer: https://ask.libreoffice.org/en/question/219198/writer-relationship-between-page-margins-and-other-typographic-elements/
(In reply to Mike Kaganski from comment #79) > Possibly useful here: an overview of the sizes in Writer: > https://ask.libreoffice.org/en/question/219198/writer-relationship-between- > page-margins-and-other-typographic-elements/ Awesome! Please put it into the online help or at the wiki. Reminds me on bug 103683 that could be incorporated in such illustration.
(In reply to Mike Kaganski from comment #79) > Possibly useful here: an overview of the sizes in Writer: > https://ask.libreoffice.org/en/question/219198/writer-relationship-between- > page-margins-and-other-typographic-elements/ That is a a wrong approach that needs to be fixed. Writer will never be a whole Word competitor and replacement until that. Body margins are defined by local standards and Writer interfere and breaking them, making it unusable.