Subject: footnotes (was Re: Multi-Paragraph Headers and footers?)
From: Paul Rohr (paul@abisource.com)
Date: Tue Mar 06 2001 - 11:44:13 CST
At 04:54 PM 3/6/01 +0100, Jesper Skov wrote:
>That said, I don't understand why headers/footers are special. The
>way I see it they're just minipages that happen to be located on other
>pages, specifically at the top and the bottom.
>
>When I think of a footer, for instance, I'm thinking multi-paragraph
>footers. Maybe because I'm thinking as an ex-LaTeX user rather than a
>WP user. Some of our university papers had footers that would spill
>from one page to the next.
I think you're blurring the following concepts?
- footers (same content repeats on every page)
- footnotes (spill over to subsequent pages until exhausted)
We do need to implement footnotes and endnotes [1] after 1.0, but for now
we're just focused on headers and footers.
>What I'd like to see are two configuration points (excuse the crummy
>ASCII art):
>
>+---------------------------+
>| header |
>| |
>+---------------------------+ max header height
>| |
>| |
>| |
>| |
>| |
>| body |
>| |
>| |
>| |
>| |
>| |
>| |
>| |
>| |
>+---------------------------+ max footer height
>| |
>| |
>| footer |
>| |
>| |
>+---------------------------+
>
>
>And if you add a footer on page 1 which is too tall to fit in the
>allowed footer space (on that page?), it spills into the footer space
>on page 2.
>
>Get it?
Yes. But again, this shouldn't be relevant for *footers*.
This kind of algorithm will be needed for *footnotes*, where you balance the
spillover of the body container(s) with the spillover of their associated
footnote container(s).
Some of the screw cases get pretty interesting, because for lines containing
footnote references, you sometimes need to decide which page to put it on
based on how much content is left from prior footnotes. Don't even attempt
these container-juggling algorithms until you grok widow/orphan control,
because these can get a lot screwier.
>What this means is that the layout code is the same (hopefully
>eventually replaced by Pango) whether used in the page body, headers,
>or footers.
>
>That is, what we should model is layout constraints for the layout
>code to work within - we should not be handcrafting special code for
>layout/editing in each of these special constraint boxes. Similar
>constraints control how the cursor should be have when leaving a
>constraint box (i.e., leaving body on page 1 should move it to the
>body on page 2, not the footer on page 1).
In general I agree. Once you're inside a particular container type
- header/footer
- body
- note
- etc.
there should ideally be very very little special-case formatting logic.
(The default styles may differ, but little else.) Most or all of the logic
for that type of flow should happen at a higher level -- presumably the
container.
The one exception that comes to mind are editing operations for flow-control
primitives (inserting section, column, or page breaks) -- none of which are
relevant for unflowable containers (such as headers and footers).
I doubt that our classes express any of this yet, but they should.
>Hm, maybe this is halfway into pagesetter land, but wouldn't it be
>exceptionally cool if we in simple ways could allow the user a good
>control of the page layout? We already have controls for page width
>and height, why not controls of where footer/headers should go?
What did you have in mind? Generally, people want their headers to take up
"just enough" room at the top of the page. Ditto for footers at the bottom.
I'm not sure more complexity is useful.
Paul
[1] Note that endnotes are somewhat easier to implement than footnotes,
because the entire note flow just takes up page space in the section after
the body flow.
This archive was generated by hypermail 2b25 : Tue Mar 06 2001 - 11:36:47 CST