expanded header/footer capability on export

Well, this suggestion for version 2.0 would save me some hassle, and I don’t think it would be very hard to implement for RTF exports.

Currently, only a single-field header or footer can be defined, with boolean control over whether the header is printed on the first page or not. However, in RTF, there are some other possibilities.

First, one can certainly have headers as well as footers, using the \header* and \footer* directives. This would be as simple to implement as adding the field(s) in the export preferences and writing out a fairly simply bit of code in the document header.

Second, three-part headers should very easily to implent simply by embedding headers into a paragraph with a centering tab in the middle and a right-adjusted tab just before the right margin. The left-center-right pieces of the header would simply have a tab between them. So, instead of having a single field for a header or footer, there would be three for each (possibly blank, of course). I actually have tested this one, writing a sed(1) script to modify the document header of Scrivener-exported RTF by inserting a tabbed paragraph, but it would be much better to have it be “out of the box”.

Third, there is a \titlepg directive that enables \headerf and \footerf directives; these allow the first-page header/footer to be different from on subsequent pages. Once again, this should be relatively easy to implement, simply by adding the requisite fields in export preferences and writing out the directives in the document header. (This would be especially useful for formats such as APA6 that require a different first-page header. In that case, the left-aligned portion of the first page must have “Running head: BLA BLA BLA”; the right-aligned portion simply has the page number. Subsequent pages must change the left-aligned portion to just “BLA BLA BLA”.)

Fourth, and to me this has the least “bang for the buck”, there is a \facingp directive that enables “l” and “r” versions of \header & \footer (e.g., \footerr, \footerl). I don’t know whether Scrivener users have any need for this, I don’t think that I do. The \facingp directive also enables “gutter” options that in effect allow one to leave room for a binding on the inner margins of each facing page.

In my imaginary view of Scriv 2.0, I can see a separate export panel for headers and footers containing two 3x3 sets of blanks, with left-center-right headers represented by the three columns, and the first-page, left-page, and right-page represented by the three row in the two sets, the upper set representing headers, the lower one representing footers. Radio buttons would modify this array by enabling/disabling first page and facing page mode; if first-page mode was enabled with nothing in the headerf or footerf blanks, that would be equivalent to the current “no header on first page” mode, but there’d be no harm in having a button for that as well. If facing page gutters were supported, there would also have to be a new blank to enter the gutter width, probably in the margins section of Page Setup, with a default value of 0.

I can’t imagine any reason why any of these should be supported when importing RTF or in the editor.

Finally, output formats other than RTF may not support these things at all. For example, HTML has no footers and only one header (title). It would clearly be useful to export them in a form that, e.g., latex could read; also, docx, oo, etc. probably can handle all of these very easily but I am not familiar with their internal representations.

Greg Shenaut

Hi Greg,

2.0 will certainly support three part headers and footers (and both headers and footers). Different first page header/footer is on the list, too, although I probably won’t be adding different right/left headers and footers as that adds a lot of options and veers off into word processor/layout program territory.

This will only apply to RTF and printing, though. While .docx and .doc etc support these things, I rely on the OS X exporters. Modifying the RTF output is, if not straightforward (modifying what is generated is trickier than if I was doing it all myself, but doing it all myself would take years of working on my own RTF parser), then certainly do-able. But try peeking at the .doc and .docx formats and you’ll see that there’s no way I could graft these things on there.

All the best,

That sounds really good.