Yes, please attach a test document and the resulting pdf-file and if possible a screenshot with multiple pages (see status bar) after reopening the document.

You do not describe, in which file format you have saved. But it is essential, whether you use ODF or an alien format.

Created attachment 104917 [details]
test doc

Test doc saved with the correct settings.

Created attachment 104918 [details]
test pdf

PDF that shows the correct layout of the headers and footers.

Created attachment 104919 [details]
bad doc

Doc saved just after opening; has munged headers and footers

Created attachment 104920 [details]
bad PDF

PDF that shows munged headers and footers

Oops. I saved the doc using native .odt format. Attachments added.

Created attachment 105261 [details]
shows random BOLD words in both footers

Every time I open the ODT file different words in the footers go bold

I regularly write a 20 page newsletter with LO Writer with pages which have headers and footers. The footer looks as follows:

10     Bowen Mountain Association Newsletter – September 2014

Every time I save and then re-open one of the the ODT files, one or more of the words in the footer have turned to BOLD - always different words. Other times the page number which is meant to be BOLD has gone non-BOLD. When I mark the whole of one of these words, the BOLD button does not show it is bold. I have to put just the cursor in the middle of one of these bold words which then brings up the BOLD button, which I can press, which unboldens just the one word. Other bold words in the line are not changed. Every time I open one of the files I have to check all the footers and unbolden all bold words which have reappeared before I finally export the file to a PDF for printing. Never seem to have this problem with the headers. I am running:

LibreOffice Version: 4.1.6.2 Build ID: 410m0(Build:2)distributed with 
OS: Linux 3.11.10-17-desktop openSUSE 13.1 (Bottle) (x86_64)
Processor: Intel(R) Pentium(R) CPU B940 @ 2.00GHz - dual CPU
Memory: 1 GiByte
Drive: TOSHIBA MK3276GSX - 298.1 GiB

Related attachment:  shows random BOLD words in both footers

Last time I opened the attached file the word "Bowen" and "Association" were BOLD in the first (left odd) footer and the word "Association" and "Newsletter" were BOLD in the second (right even) footer. But this varies.

I opened John's doc three times and it displayed the footers differently each time: random words bold, random normal.

Thanks Neal for confirming that this bolding and unbolding in the footers really happens. Were you using LO 4.3.0.4 release? That is a newer Version than my 4.1.6.2. I am surprised nobody else has picked this up - it is so annoying.

Should I make this a separate Bug Report. I would like to have it in the main Index. How do I do that. I am a newbie on Bugzilla and I would appreciate help.

(In reply to comment #10)
> Thanks Neal for confirming that this bolding and unbolding in the footers
> really happens. Were you using LO 4.3.0.4 release? That is a newer Version
> than my 4.1.6.2. I am surprised nobody else has picked this up - it is so
> annoying.
> 
> Should I make this a separate Bug Report. I would like to have it in the
> main Index. How do I do that. I am a newbie on Bugzilla and I would
> appreciate help.

Yes, using v4.3.0.4.

Looked at your effect again. It doesn't just change normal/bold. Click in the middle of a word and type some characters. They might or might not be bold, but LO thinks they're of different size (that is, 10 != 10).

I'd leave it here for now. It shows that more than one user is affected, and that it's existed for a while. Leave it to an LO developer to split the report.

The problem is minimally better with version 5.1.1.3 (.deb on Debian Jessie, from jessie-backports). When I have time to try again, I'll install the latest .deb from libreoffice. I did try v3.3, but it gave me a SIGSEV.

Pictures seem to remain centered now. Footers seem to behave now.

Alas, the header problem is worse. It ... wait. Oh, I see. When saving the doc, the program sets the 'before text' and 'first line' to 1.2" and -1.2", respectively, in each individual paragraph in the header even though I applied a central style to each; the central styles do not have the 1.2" offsets. I just fixed them, saved, exited and restarted. And the 1.2" offsets are back.

... Oh, great. Now when I page up quickly, loffice thinks there are 10 or more headers on each page.

There's *definitely* something screwy in page header operations. Is it possible I just have a badly munged doc that needs to be cleaned out by hand?

The header and footer problems re: mishandling tabs stops, etc., when opening/reading the file remain in version 5.2.6.2 (Debian Jessie).

Comment 13 is still valid with respect to the 1.2" problems: the header and footer paragraph styles are still altered when the doc is opened after being saved with the correct settings/appearance. And it still draws lots of the blue-ish footer 'tabs' when paging up and down.

So this issue still exists and is unchanged.

From the help window:
Version: 6.0.5.2
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group

(In reply to Neal Murphy from comment #18)
> And it still draws lots of the
> blue-ish footer 'tabs' when paging up and down.

Sorry. It happens to footers *and* headers.

This is not correct bug report. It wasn't triaged properly. 
Bugzilla is "issue based", so a single issue must be pointed at, after a search for not being a duplicate. Bugzilla is not "document based", like "this document doesn't display nice". 
Each issue (section break, paragraph break, text box size, picture position...) should be analyzed and first checked for already reported bugs.
If bugs don't exist, they should be reported separately, even if they happen with the same file. 
Example file should be reduced to minimal test case for a specific problem (no excess pages or text) with clear file history or steps to reproduce from scratch.

You need to write exact verifiable facts for s single issue. Otherwise, it's more unlikely bug will be dealt with. 

Reproducible steps:
1. open attachment... (minimal test case)
2. set...
3. save and reopen
...
Actual Results:
Expected Results:

In this case, if it's header, you didn't explain how you fix it. "offsets" were directly formatted, not via style. Please note that attachment 104917 [details] and attachment 104919 [details] look same.
If you directly correct all paragraph indents to 0 in attachment 104917 [details], header looks OK after save and reopen. Tested with LO 6.0.6.

"blue-ish footer 'tabs' when paging up and down" Another issue, I guess Bug 46988.

I'll close. Feel free to write reproducible steps if you think there's bug to be resolved here.

Bug 46988 has to do with jumpy scrolling. There is nothing in that report about LO creating tens of the blue-ish tabs that identify headers and footers, so many tabs that it can take LO a second or three to render all of the tabs it generates for a *single* header or footer on a 4.4GHz CPU with 16GiB of 2.1GHz RAM).

"If you directly correct all paragraph indents to 0..." *That* is the exact problem; you deftly sidled right past it. That you had to 'directly correct the indents' proves that the problem exists. In version 6.0.5 and previous versions going back at *least* four years, LO/OOo silently *changes* those indents, either when they write the file or when they read the file. I should not have to fix the indents every time I open the file. File 'test doc' was saved immediately afer I set the correct indents. File 'bad doc' came directly from 'test.doc'; I opened 'test.doc' and immediately saved it as 'bad.doc', making no changes.

  - Did you look at the PDFs that clearly show the differences?
  - Did you compare the XML of the two ODT files to see how they differ?
  - Did you test on any older version to verify the problem?
  - Did you test on Linux?
  - Did you report the change that fixed the problem (if it was, indeed, fixed)?
  - Did you report any other bugs that correctly report the issues I see with headers and footers?
  - Did you attempt to help us (the complainers) identify and clarify the issues, potentially
    creating other reports?

The only request I've seen in this report in the four years since I opened it was Regina's request for example docs and PDFs and for me to identify the file type I used. I did so. And outside of Regina's and John's comments, the integrated circuit asking me to verify the continued existence of the problem, and my updates, I've heard only crickets. Until today when you 'resolved' the problem by declaring the way I reported the problem to be 'invalid'.

Bug 46988 has to do with jumpy scrolling. There is nothing in the report about LO creating tens of the blue-ish tabs that identify headers and footers, so many tabs that it can take LO a second or three to render all of them.

On my project, I work with users and developers to triage and identify problems. I give them methods to reduce and reproduce the problem. I examine the source code. If the problem was already fixed, I tell them what the error was and which version has the fix. I tell them if the problem was inherited from the version before I took over or if it was my own mistake (be it due to oversight, stupidity, or ignorance). And, yes, I do install and test old versions of my project when necessary because developers and users earn that much respect just for taking the time to report a problem.

I submit that your response action are invalid. I submit that the problem should remain open until changes can be identified that actually fix the problem.

Lest I seem ingrateful, thank you for reproducing the problem. At least I know it's not something weird on *my* computer.

If bug is not reproducible (steps) and clear (actual and expected), it's unlikely to be resolved, ever. 
Moreover, you confirmed the bug yourself, without repro steps, which is not permissible. 

Header indents in "test doc" ODT attachment 104917 [details] are already wrong on fileopen.
Moreover, header paragraphs are level 10 Outline. 
Question is where this outline-level="10" comes from. 
As written, if paragraph indents are directly corrected to 0 or outline removed and than document saved, documents opens fine. Test with reported 4.3.0.3 and master 6.2+. Issue never confirmed. 

Bug report is invalid, mostly due to not proper and timely triage. I hope it's better nowadays. But we have to do some cleanup. 
Still if you can provide requested steps and results with minimal test case, you're welcome to submit another bug report. 


Note: I see another issue with attachment 104917 [details]. It used to be 4 pages up to LO 5.2 and from 5.3 up to now it's 5. Reason is "Note" section on page 4. 
Here we have 2 differences that probably have different causes:
1. tab length before "Please note"
2. increased text spacing 
Issue 1. I find not important enough to pursue. 
For issue 2. I cannot grasp the reason. It would be interesting to determine.