New page style, inherited footer

English
#1

Hello,

I’m looking for a feature that I would describe like “inherit footer content from the previous page which has a different page style”.

To be more specific here’s what I do:

  1. I have a Writer document (OpenDocument format) with page style style_A. This style defines both footer and header.
  2. I need next page with identical footer as on previous page (style_A) but with different header or no header at all (actually no header in my case).
  3. So I create new page style (style_B) and I set style_A’s “Next style” to “style_B” and style_B’s “Next style” to “style_B”. So the sequence of pages is style_A, style_B, style_B…
  4. Next page is indeed in style_B and I can define new header (or set no header), but how to instruct Writer that I want inherit style_B’s footer after style_A?

LibreOffice Writer 7.4.1.2 (x64) on Windows 10
I always save my documents In OpenDocument format.
I don’t use chapters in this document (maybe I should?)

Thanks in advance for your answers.

#2

Unfortunately, you can’t. No such feature at the moment. Just copy the content from the previous footer, and update all identical footers one by one, when a change is needed.

#3

Edit your question (= modify it, don’t answer with a comment) to improve it. What kind of header do you need on the first page as opposed to the one on subsequent pages? What is your sequence of pages (Style_A followed by several Style_B)? A chapter?

There may be alternate solutions to independent page styles:

  • “polymorphic” page style by unticking Same content on … in Header and Footer tabs of page style configuration
  • use of fields in the header if your header can be “deduced” from your text

Don’t forget to mention OS name, LO version and save format.

#4

@ajlittoz

What kind of header do you need on the first page as opposed to the one on subsequent pages

I’m not sure what you mean by “kind of header”.
I have plain text, an image and fields in first page header. There are also conditional hidden paragraphs.
Next pages have no headers.

use of fields in the header if your header can be “deduced” from your text

Yes, I had a similar idea: create a non-printable frame, define some text variables in it and use those variables in both headers (in style_A and style_B).

#5

Is this a chapter title? book title? fixed text? …?

Bad idea, they don’t work well in headers (because of the time the condition is computed; from experience, the first time the page style is met, which prevents “dynamic” update depending on current state of the variables).

You’re in the ideal case to use what I call “polymorphic page styles” but give more details about document structure.

  • if you have a single sequence as cover page + running pages, the simplest is:
    • style your cover page as First Page with header
    • all subsequent pages are automatically Default Page Header without header
  • if you have several chapters where you want the first page to be different:
    Configure your Header tab in Style_A page style unticking Same content on first page. Enter a header in the first page of the sequence and delete it in the second page (valid for all subsequent pages). These headers are independent from each other.
    When you want to restart for another chapter, Insert>More Breaks>Manual Break and force the page style to Style_A (this may look strange to request the same page style but it results in restarting at the first variant of the page style). Of course, if the header should be different for every chapter, it must be generated from fields.

Avoid frames when they are not part of the logical structure of your document. Each frames creates an independent flow. This flow is scanned separately from the main one. So, if data contained in the frame is supposed to be related to data in the main flow, you can’t ensure it will be available when you reference it in the main flow (frames are not scanned when their anchor is met in main flow but either before or after main flow; order of frame scan is unpredictable – seems to depend on chronological order of insertion in the document).

And it is even less predictable if you use frame data in header or footer.

If your only motivation is “non-printable variable definition”, create a paragraph style with Hidden attribute. But tick Hidden characters in Tools>Options, LibreOffice Writer>Formatting Aids to have a visual clue on screen (with View>Formatting Aids).

#9

Yes, as far as I can recall I’ve faced this issue in the past, but it (i.e. conditions in headers/footers) works good for me, in particular in this document.

Here’s the document. I implemented “footer variable frame” in it and defined separated “next pages footer using variables”, and it works correctly.
firmówka23.odt (25.6 KB)

I just place these “variable” frames in the very beginning of this document.
I thought this could be remedy, but you say it is not.
There are two frames with this purpose in my document. One of them was created at the very beginning of creating this file, the second one - minutes ago. In both cases variables defined in them are properly propagated in entire document.
I suppose I just was lucky. But anyway - is there really no way to make it more deterministic?

Thank you for your helping.

#10

When you want to define data which is “constant” all over the document, the best place to do it is File>Properties. You insert them with a field from the DocInformation tab, Type Custom and the name you gave. I have done that in the revised sample file.

Since I don’t know what you want to do with “No firmowce”, I left it where you put it. If if keeps the same Yes/No value all over the document, record it in File>Properties where you have a dedicated format for Yes/No.

Your use of sections in header and footer is faulty IMHO. Though it is perfectly legal in header and footer, I never did so because header and footer contain only short “titles” which are not expected to be handled by a complex text flow management. A section is meant to temporarily change the number of columns in a page with text flowing from one column to the next, with optionally balanced height. Your definitely not in this case in the header/footer.

I removed the sections there (all the more since you have nested sections in the footer).

The nature of data in the footer suggests to use a table which avoids the flow issues. I also made the last column wider to accommodate the email address. I changed the image anchor to As character so that the image size governs the footer height (which was not the case as To character. The image then aligns according to what is configured in the paragraph style.

I didn’t change the footer in FirmowkaNastepneStrony page style. You can do it easily (this is a good home exercise).

Your use of tables at the beginning of the letter again is clumsy. For the “date” paragraph, define a dedicated paragraph style with a right-aligned tab stop at right of printable area. You enter your first data as usual (the entry field), then Tab for the date field.

There is no need of a table for the addressee (if this is it). You have a built-in paragraph style Adressee awaiting proper configuration for this role. Adjust spacing above and below; change Before Text indent to start at middle of a line and you’re done.

I don’t know if it is your sample or your routine. Your text is Default Paragraph Style. This is an error because this style is intended to define “universal” attributes shared by all other styles. It comes into play when you want to manage smartly the appearance of your document. The Writer-standard style for text is Text Body.

Styles are your best friends. Learn how to use them. At least, read the Writer Guide.

Corrected sample file: firmówka23.odt (25.0 KB)

#6

There is no style hierarchy for page styles, so no proper way to have inheritance of page properties, as @mikekaganski and @ajlittoz already indicated.

As a possible workaround, you could use bookmarks to have content propagated, in a way that looks somewhat like inheritance.

When using bookmarks in marginalia, updates are not always smooth. A manual refresh, or save/reload, may be required after editing the original.
Also:

  • When you edit the content you may “lose” the bookmark connection on inserted parts.
  • You cannot easily edit the “child content” (linked field). This should not be an issue with proper inheritance, but with this workaround you need to edit in the “mother” (or source) end. You can of course combine bookmarks arbitrarily, but that makes editing and maintenance even more of a risky sport.

Rough mockup in attached file.
test.odt (9.6 KB)

#7

A few comments:

  • Bookmarks are intended for navigation within the document. Though they are in all practical aspects technically equivalent to cross-references, prefer cross-refs when you don’t intend to use them as scroll targets
  • Placing bookmarks/cross-refs in a header is risky: headers are repeated on every page (of the same page style), therefore their location is not known and ambiguous. It causes issues in some contexts. And this explains the refresh problem you noticed.
  • IMHO, it is preferable to define the “constants” in a dedicated block of paragraphs near the beginning of the document, chapter, … creating variables. This block receives attribute Hidden so that it is not taken into account in the text flow. If the “constants” are really constant over the full document, use File>Properties to create custom entries which are later inserted with fields.
1 Like
#8

I agree, there are serious pitfalls with the bookmark/cross reference strategy. Should have tagged my answer as “quick and dirty”.

The main advantages are that you edit “visually in place” and with a bookmark, a click on a linked entry takes you to the source, where you can edit.

Not every user will relate to the abstraction of variables. For those who will, escalating the learning threshold is certainly worth the effort.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.