Subject: Re: header/footer sections (was Re: Run rewrite status [2001.02.16 - 20:50 CET])
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri Feb 16 2001 - 20:14:42 CST
On Fri, 16 Feb 2001, Paul Rohr wrote:
> At 08:53 AM 2/17/01 +1100, Martin Sevior wrote:
> >You'll need to put in code to determine in you're in edit header/footer
> >mode and while in this mode you have to retrict the range of allowable
> >positions to just the header/footer section your editing. Otherwise you
> >can easily jump from a header to a footer or to a header/ footer of a
> >different doc section.
>
> IIRC, most of the code we have for walking back and forth through strux had
> to have special-case logic to go up and out to the next level. Policy
> decisions about whether to continue walking "out" like this can be
> controlled by an optional bool argument, no?
I introduced a new method into fv_View, getEdittableBounds() to prevent
the point flowing into the header/footer region at the end of the doc.
I've made a unilateral decision that the header/footer sections should be
placed after the regular text in the document.
>
> >There is a major problem with editting header/footer code. The
> >hdrftrSection is not formatted.
>
> Yeah. I wondered whether that approach would continue to work well when we
> had to start editing.
>
> >All the run's in that section have NULL
> >pointers for their lines. I did this because I didn't want lines without
> >pages. Only the shadows of the hdrftrSection have containers. Now it might
> >be we can live with lines in hdrftrSections but I suspect it will lead to
> >problems. I don't think I've traced through all the places where runs with
> >no lines will cause segfaults either.
>
> I'm not sure I understand. It's pretty easy to envision documents which
> will want to have multi-line headers and/or footers. (In fact I'm pretty
> sure I've already hacked documents which used that feature.)
>
> Does this not work?
>
Yes multiline header/footers SHOULD work (not that I've tested them) but
those fp_Line (s) are pointed to by fl_hdrftrShadow's fl_BlockLayout's
not the overall fl_hdrftrSection blocks.
> >I put editting headers/footers in the too hard basket for now but if you
> >want to try to make it work, go for it :-)
>
> Yeah. The biggest problem would be how to reflow the other containers on
> the page as the headers grew or shrunk.
I wasn't even thinking of this. I put in code to clip text outside the
boundary (which has been tested)
If we want this we have to adjust the header/footer's on the fly we have
to do a bit more work. It's not too hard but it might be better to wait
for post 1.0 we when go through a major container rewrite in order to
accomodate frames and Tables.
To that end I suggest that your fields as containers also be shelved to
post 1.0. All that layout code has to be substantially re-visited anyway.
I think adding that to pre-1.0 at this stage would add at least 2 months
to the release date. At the very least.
Cheers
Martin
PS. I don't think would be hard to work around a 1.0 format anyway for
2.0. We can afterall import Word docs and they're much different :-)
This archive was generated by hypermail 2b25 : Fri Feb 16 2001 - 20:14:58 CST