Bug 35900 - Last page loses headers footers
Summary: Last page loses headers footers
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: x86 (IA32) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Header-Footer
  Show dependency treegraph
 
Reported: 2011-04-01 23:20 UTC by Elmar
Modified: 2012-05-10 01:38 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Reconstructed sample document for bug 35900 (41.42 KB, application/vnd.oasis.opendocument.text)
2012-05-01 09:36 UTC, Roman Eisele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Elmar 2011-04-01 23:20:43 UTC
My document (23 pages) has an endnote (only) on thelast pages.

No headers / footers are shown in view nor do they then print.

Second last pages shows "22 of 23".
Comment 1 Jan Holesovsky 2011-04-07 10:15:02 UTC
Please provide the document in question.  Thank you!
Comment 2 Björn Michaelsen 2011-12-23 11:51:14 UTC
[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:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 3 Björn Michaelsen 2011-12-23 16:59:55 UTC
needinfo keyword redundant by needinfo status.
Comment 4 Roman Eisele 2012-05-01 09:33:35 UTC
I tried to reproduce this bug today. Using LibreOffice 3.5.3.2, German UI, running on MacOS X 10.6.8, I created a similar document (according to the sparse information given in Summary and original description) with 24 pages and a single endnote, and will attach it to this bug report for easier reference. Finally, I found that most probably there is NO bug here at all, but IMHO a simple misunderstanding.

If you add headers and footers to a simple document, they are added to the 'Default' pagestyle. But if you create an endnote, it is placed on a new page at the end of the document which has the 'Endnote' page style. For the 'Endnote' page style, the header is empty by default (and there is no footer by default). If you want to have the same headers and footers on the endnote page(s), just go to the page(s) where the endnotes are placed, enable header and footer and add the same header and footer texts as on the other pages of your document. Then the pages with the text of your endnotes will just look like the other pages of the document.

So IMHO this is no but at all, but a simple misunderstanding. Its background is the fact that the change of the page style before the (1st) endnote is not emphasized visually (no manual page break etc. -- why?), and therefore the user can easily overlook that the page style has changed and that he must add headers and footers again. Maybe we could improve the visual experience of endnotes handling a bit ...

I close this bug as RESOLVED/NOTABUG. If my explanation of the problem is wrong, and if there is a real bug here, feel free to re-open this bug, but then please add a long and helpful description explaining what exactly goes wrong and why this is really a bug ;-).
Comment 5 Roman Eisele 2012-05-01 09:36:34 UTC
Created attachment 60859 [details]
Reconstructed sample document for bug 35900
Comment 6 Elmar 2012-05-01 23:44:29 UTC
(In reply to comment #5)
> Created attachment 60859 [details]
> Reconstructed sample document for bug 35900

Yes, Roman is right. 

I come from 20+ years of using MS office tools. Where, as many will know, page styles are not well implemented.

It would be a time saver if page styles could also inherit from Default (like paragraph styles can).

Ditto list styles.

But I accept that this would be for a future release.

What would also be helpful (does this exist already?) is if it was possible to restore a child style to the parent it is linked to through the click of a button. Sometimes anomalies arise because one modifies a style and then modifies it back to the attributes that could be inherited from the parent. Makes for a messy document (esp if this is then turned into a template.)

I am still new to Open Source (having come all the way from MS DOS 1.0), but I cut my teeth on CP/M and liked the control that Wordstar and WordPerfect gave one over the format of documents.
Comment 7 Roman Eisele 2012-05-02 01:53:49 UTC
Reset 'Version' to LibO 3.3.1 release: 'Version' should show the FIRST version of LibreOffice which shows the problem, not the last one.

Changed 'Platform' to 'All': according to comment #4, not a Linux-specific issue, but a general issue.
Comment 8 Roman Eisele 2012-05-10 01:38:05 UTC
(In reply to comment #6) 
> It would be a time saver if page styles could also inherit from Default (like
> paragraph styles can).
> 
> Ditto list styles.
> 
> But I accept that this would be for a future release.
> 
> What would also be helpful (does this exist already?) is if it was possible to
> restore a child style to the parent it is linked to through the click of a
> button. Sometimes anomalies arise because one modifies a style and then
> modifies it back to the attributes that could be inherited from the parent.
> Makes for a messy document (esp if this is then turned into a template.)

Hello Elmar,

I can confirm that your ideas about improving the page styles / list styles handling are well-considered and useful. For the 1st one, the improvement of page styles, I have found an existing feature request, bug 41316; you could leave a comment on it to show the importance of this request, if you want ...

For the two other ideas, I have not found an existing request yet, but maybe we will find one, or you could create a new one (one feature request per idea, of course) -- this would be very helpful, I think ... It is hard to say if/when these request will get implemented, of course, but having good, well-considered feature requests with a good descripton of the feature and good arguments for its importance are always good.