Subject: Re: Multi-Paragraph Headers and footers?
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 07 2001 - 20:21:50 CST
At 09:24 AM 3/8/01 +1100, Martin Sevior wrote:
>Yes, you're exactly right Paul. We independently discovered it :-) I've
>just implemented a "fp_VirtualContainer" for the overall
>hdrftrSectionLayout which has nops for the draw and clearscreen methods.
>Thanks to everyone who told me about the right way to C++ design earlier.
Good, then I'm not crazy.
>I'll commit some code with a some big advances in the
>editable header/footer code soon. We will have editable multi-paragraph
>headers/footers in V 0.90.
Sweet!
>Yes. I think you're right. I guess Eric had not got around to doing this
>before he left to run SourceGear.
Yeah, IIRC, the original design was a quick dogfood effort on his part -- he
snuck in non-editable headers and footers because he had a document he
needed to print with page numbers.
>I've had to write a lot of code. Still
>the overall idea of shadwo sections for headers/footers works with a bit
>of shoehoring I think.
Cool. I'm glad it's working out so well.
>> Conceptually, headers and footers should just be another kind of container
>> that the layout algorithms use when constructing pages. Their contents
>> don't reflow to other pages -- instead, they expand to allow their
contents
>> to fit, stealing space from the body of the page.
>
>I don't know if I will do this. I might just clip them and let the user
>change the margins via pagesetup.
How hard would it be to reflow the body content to adapt to the header size,
instead of just clipping?
I can envision headers and footers working in any of three ways:
1. Growing "inwards" and squeezing the body content to make it smaller. We
already have contraint logic which decides how much of a page should be used
for the body container(s) based on the page margins. The idea would be to
allow even less room if the headers / footers need more.
2. Growing "inwards" towards the body and getting clipped (or drawn
underneath). This is a special case of #1, no?
3. Growing "outwards" from the body container towards the edge of the page.
If there's not enough room, content gets clipped by the physical edge of
the page, although we'd probably need explicit clipping code to avoid
display or printing bugs.
Depending on which of these you choose, the interpretation of how to place
the header/footer boxes relative to the top and bottom page margins can be
very different.
- You can simplify your life by always requiring that the two boxes be
adjacent, or
- You can get a different effect by assuming that all such containers have
a top and bottom margin.
It's been a long day, so I won't run though all the cases now. (This kinda
feels like a good point for a power user like Randy to pop in and tell us
how it should work.)
>Actually we should put some handles on
>the left ruler so the user can interactively change margins like the top
>ruler.
>
>Anyone interested?
This would be a nice way to finish off step III of the following POW:
http://www.abisource.com/mailinglists/abiword-dev/00/March/0014.html
Bruce has already zapped step 2, so be sure to consult the relevant checkins
for ideas.
Paul
This archive was generated by hypermail 2b25 : Thu Mar 08 2001 - 00:14:30 CST