How to Add current H1 and H2 to page header?

English
#1

I would like to put the current H1 header in the left side of the page header and current H2 header in right side of the page header. When the person pages through the document they know where they are in the document by looking at the top of the page, what the current H1 and H2 headers are.
I found 2 topics and don’t understand them at all.
Adding chapter names to Header; formatting
Writer: How to add First and last H1 name to Header?

I was hoping I could just add a variable reference like “[H1]” to the left side of the header and “[H2]” to the right side of the header like I could the page number variable. How complicated can it be?
TIA

#8

ajlittoz, thanks for the detailed answer. With your help I got it to work. :slight_smile:

My only problem is sometimes the H2 header is too long. I have it positioned on the right side of the header and a long H2 header will wrap to underneath the H1 header on the left side of the page. Is there a way to force H2 to wrap on the right side of the page?
TIA

Example:
H1_HEADER_IS_OK                 H2_HEADER_IS_LONG AND_MAY
_WRAP_UNDER_H1_HEADER


… I ended up right justifying the H2 field in the header and it works reasonably well. Is this the best way to do it?

#2

What you call “variables” are fields in LO Writer parlance.

I assume you already know how to activate header.

  • Put your cursor in the header area. Insert>Field>Other Fields and go to the Document tab. Select Chapter in Type and Chapter name in Format, Insert for level-1 heading.

  • Type two Tab characters to align to the right margin (paragraph style Header is already configured with the adequate tab stops). Repeat the previous action with additional selection of Level 2 for level-2 heading.

Important remark: Writer captures the headings in effect in the first paragraph of the page. If the first paragraph is a Heading 1, level 2 does not exist yet. Writer returns then the level-1 heading for the missing level-2. Therefore, everywhere you change chapter heading (and this chapter heading is at top of page), you’ll get twice the same information.

This is not a bug but a design fall back action.

PS: the articles mentioned in your question address slightly different issues.

#3

Okay, so it’s a deliberate decision by the developers. That still doesn’t mean it’s the right decision. It’s a design error.
Version 6.4.7.2 on Linux Mint 20.x: The header will display the first occurrence of a Heading 2 paragraph on the current page, even if it isn’t the first paragraph on the page, but it will not find it farther down on the page when it’s preceded by a Heading 1 paragraph, not even when the Heading 1 paragraph is not the first paragraph on the page. Basically, display of a lower level heading will always be suppressed by a preceding higher level heading, which completely destroys the point of having lower level headings in the header.
For instance: imagine a typical document where each new chapter starts with a centered, large chapter title, where you normally suppress the chapter title in the heading because it’s in your face, and you do want to reference the first heading 2, which is a few lines down on that page. You will still get the chapter title in the header. I don’t want to be rude, but that’s stupid.

#4

I do agree it is a serious shortcoming. In an old AskLO post I explained in details how it works.

When you put this information in the footer, there are less problems (though there are still remaining) because the full state of the page is known. In the header, you’re in “forward-probing” mode and your scope is limited to first paragraph.
In the footer you are still confronted to non-existent levels: if the current state is level n at bottom of page and you request level n+m, you’ll get level n data and not “void”.

Do you think returning “void” instead of the current fall-back would be better? Anyway, this should be a user choice to opt between the behaviours.

#5

I’d like it to behave it in such a manner as the user wants it to behave. Remember the headers in a dictionary, displaying the first and last items on a page in the header? It should be possible to do that (I agree that it’d be difficult, it’d require allowing referencing character styles in fields). Now, the developers decide for the users what they can put in a header, and how that will behave. They should allow for more flexibility. If a user wants the present behavior, fine. If (s)he wants other behavior, it should be possible to do so. Just add a flag for First on page or Last on page occurrence to the field, and it should work.

#6

There may be a misunderstanding. I’m no developer. I was just trying to think about a specification to submit to developers.

There is already a contorted way to have first and last Heading n in the header or footer: an ugly hack with frames anchored in header or footer and offset to the other end of the sheet. Dirty and not easy to grasp for casual users.

The point here is about non-defined Heading n and “later” defined Heading n. By non-defined, I mean there is no such heading in the page or the preceding ones: clearly the field should return “void” if we don’t fall back to m < n. “Later” defined covers the case where Heading n appears somewhere down the page. Presently it can’t be captured. You can’t even hope to capture it at bottom of page because another Heading n could have occurred before the end of page.

I have no idea how it should be handled. Deferring till we have the end of page could lead to formatting loop: the field is just marked for later update, occupying no space. When we reach the end of page, we have the information and we can replace the field with its “value”; but this causes the page to be reformatted and may change the location of the end of page, needing again the page to laid out from fresh. And this can modify the “value” of the field. Starting the loop over.

#7

:rofl: Come on, I know that you aren’t a developer. My previous comment isn’t a bug report or enhancement request. It’s just my two cents.
Anyway, maybe what I ask for is too complex for a word processor. It would certainly require an update of the ODF definition. So, for the time being, it’s out of the question. Too bad, really. All of this is very much off topic, btw.

#9

I see the issue too with the H2 header, but I can live with it for now. I can’t say what the best solution is, except to ask

How does MS Word handle it? If someone switches from MS Word to LO Writer, it would be ideal if it was as compatible with MS Word in this respect. It has been years since I used MS Word so I can’t remember how it handled this problem.

#10

It sounds to me like the behavior of an HTML Editor is being asked for. Just my personal opinion though.

#11

Not really. HTML doesn’t have a notion of pages, so it doesn’t have page headers either.

2 Likes

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