Follow-up Comment #4, bug #62825 (project groff):
[comment #3 comment #3:]
> So it seems that groff does a single pass through each page from
> top to bottom: start a new page, then print the header, then
> print the body, then print any footnotes, then lastly print the
> footer. It then starts the next page.
...
> So is that how groff works? Or does groff ever "go back", upward
> to return to the header for additional formatting?
This is generally how troff-family formatters work. In groff, it extends to
everything from the way running text is formatted to the way tables of
contents are handled.
To expand on these points, if you're unfamiliar with some of groff's basics:
* Paragraphs are formatted line by line, meaning that once a line is set, it
isn't modified even if a slightly different adjustment would give better
adjustment results on a later line; this drawback has been remedied in some
other modern troff variants, and is a much desired change for groff (bug
#40716).
* Since the page numbers are not known until all the relevant pages have been
processed, troff cannot generate a table of contents indicating the page
numbers until all the relevant pages have been processed. One of two
workarounds is generally used for this: a two-pass system, or having groff
output the table of contents at the end, and a postprocessing tool reordering
the pages to move it to the beginning.
The particular issue you're noting is less entrenched: although -me does in
fact process a page in the manner you surmise, it _could_ have implemented it
differently: troff does give you the ability to move up the page, so the macro
package could leave a gap at the top for the header, process the entire page,
then, at the bottom, fill in the footer, move up the page, and fill in the
header.
But in general, you wouldn't want this, because that would give you incorrect
headers in some cases. Consider a page where the top half wraps up section
1.4, then section 2.1 begins, and has a paragraph or two on the lower half of
the page. Here you want your page header to indicate section 1.4, since
that's the section in effect when the page begins, but the above-described
system would put section 2.1 in the header.
Your situation is an edge case, where a page break happens to coincide with a
section change. In this case, -me does not look ahead to see that the very
first thing to happen is the beginning of a new section, so it prints what
looks like an incorrect section number in the header. But technically, this
_is_ the section that was in effect when the page began, and it is only over
the course of the page that it changed.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62825>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
