I appreciate all of the work that Martin has done on
editable headers and footers. But I think a change to
how AbiWord formats headers and footers should be made
before 1.0. When AbiWord creates a new header or
footer, it should set a center-justified tabstop in the
middle of the page and right-justified tabstop at the
right margin. This would allow the user to create 3
part headers and footers quickly and easily. For
example:
Left Aligned Text<TAB>Centered Text<TAB>Right Aligned
Text
The current approach of justifying the whole paragraph
doesn't allow for this. Multi-part headers and footers
are so common, that I think the bahavior I have
described should be the default.
The Insert Page Numbers dialog (or a more general
replacement) would need to respect the same convention.
So when the dialog is used to insert a centered page
number in the header, the backend code will actually
insert a <TAB> and then the page number field.
When the Page Number dialog is used to insert a page
number (or other field type) into an existing header or
footer (which, to complicate matters, may already
include a page number), the h/f would need to be parsed
to ensure that it is handled properly. This is more
complicated than the current scenario, but more likely
to respect the user's actual intentions. For example,
consider the case of inserting a centered page number
into a header that already includes right-justified text:
CURRENT BEHAVIOR: AW inserts a new, centered paragraph
with the page number before the existing header
paragraph. Probably not what the user wanted.
PROPOSED BEHAVIOR: Before inserting the page number, the
paragraph will look like this:
<TAB><TAB>Right aligned text
After inserting the page number, it will look like this:
<TAB>Page Number<TAB>Right aligned text
A more elegant solution would be to allow different text
in the same paragraph to be justified differently.
WordPerfect can do this, but MS Word can't. MS Word
uses the technique I described above. I think AW has
the same limitation.
An alternative implementation could use columns. But
this two disadvantages:
(1) Navigating and editing text in separate columns is
not as keyboard friendly.
(2) If a section of the header exceeds the column width,
it would wrap to the next line. This is probably not
the user's intention.
I apologize that this suggestion came so late. I hope
that everyone will agree with it and that it won't be
too much work to implement.
Thanks,
Rob Campbell
