Request for a header-footer formatting capability for PDF builds

[johnblommers]

The PDF produced by novelWriter does not provide for customized headers and footers. Consider adding a page-formatting feature that provides for the following metadata:

• Current page number %pn%
• Total pages %tp%
• Title %title%
• Chapter %chtitle%
• Scene %cntitle%
• A time/date stamp %time% and %date%

I'm thinking there should be six fields that the user can configure using the above metadata:

• Header: left, center and right fields
• Footer: left, center and right fields.

Note that frontmatter often has page numbers in roman numeral format while the main text of the manuscript has page numbers in Arabic format.

There is also a convention that chapters always start on the right hand page, even if it means a blank page has to be inserted after the previous chapter to make it so.

[vkbo]

The current PDF/print is generated entirely by Qt. At this point I don't want to write my own painter class to do this myself. This includes the issue with the page number location. Selecting long edge duplex still prints them on the right.

I have it as a potential improvement on my list to write the whole thing myself, but it isn't a priority. The print feature is mainly there for making drafts and such, not for producing final documents. For that, there's word processors. Saving the text to HTML lets you load that into Libre Office or, presumably, Word, with all other formatting intact. I still think that's the best path to extract a final project from novelWriter.

I should probably add a section in the documentation about this.

Edit: As for the chapters starting on a right hand page, there is a CSS setting for this. Unfortunately, Qt's HTML support does not include this property, so the best I can do is start on a new page. It is also not entirely true that they always start on the right hand page. Sometimes it's the left hand page, or either. That would be yet another option to add a select box for.

There's a lot that can be done with proper typesetting, and a lot of it is easier to do via LaTeX. I've spent quite a bit of time doing this sort of stuff in LaTeX myself, but at the end of the day, I don't really think it's something novelWriter needs to support. There are simply too many options to consider, and it will easily become very complicated, and there are already tools for this sort of stuff.

I do want to add an EPUB builder at some point though, or at the very least produce an EPUB-friendly HTML export file.

[johnblommers]

Let me wholeheartedly agree with these comments:

The print feature is mainly there for making drafts and such, not for producing final documents. For that, there's word processors. Saving the text to HTML lets you load that into Libre Office or, presumably, Word, with all other formatting intact. I still think that's the best path to extract a final project from novelWriter.

I should probably add a section in the documentation about this.

IMHO having the author use LaTeX to generate the final PDF product is a far better solution than Veronica reinventing this. The time is better spent either referring to a recipe for doing this or presenting one in the documentation.

But novelWriter no longer generates LaTeX output. I missed that development. No problem because the user can build a .nwd file, change the extension to .md and use Pandoc+LaTeX.

[vkbo]

Pandoc also converts from HTML, and with Qt 5.14, you can also save standard Markdown, so plenty of ways to convert the file.

[johnblommers]

Just thinking out loud here ...

Perhaps a good way to address this sort of thing in-tool is to provide for user-defined commands to be run from the menu system in novelWriter. Suppose the user has a script that outputs a camera-ready PDF for publication from HTML. Why not provide novelWriter with a Customer Tools menu that lets the user define the path and parameters to said command?

All novelWriter has to do is invoke the script with the parameters the user predefined and wait for it to finish, reporting success or failure codes, with a Kill button in case the user wants to kill the command.

[vkbo]

That would be something like a scriptable build chain, where novelWriter will run through a few tasks, and then pass the file on to an external post-processing tool.

It is doable. I'll keep it in mind for a later addition.

[vkbo]

Would it be acceptable if this instead was added to the Open Document export? I've finally written a proper ODT file converter, and adding header/footer is not a lot of trouble. It will anyway be needed for the manuscript export format (#622).

[vkbo]

So, with the now merged full ODT exporter (currently in testing and ready for 1.2 Beta 1 release #663), the best path to produce a well-formatted PDF is to use this export option and Libre Office's PDF converter. The ODT file now comes with a standard header following roughly manuscript guidelines (although they do vary). I don't think I will tinker any more with the print pathway. The PDF option has also been move to the Print button because it is actually a print to file feature, not a PDF export per say. I don't think writing my own PDF exporter is worth the effort.

I'm planning to add a separate manuscript-specific set of options, as mentioned above (see #622), where tweaking the header will be possible too. However, since the exporter has no idea how many pages the ODT file will be when opened (I'm making it paper size ignorant for instance) there is no way to determine which chapter or section ends up on which page. The header will thus be more or less static aside from page number.

Since I'm not going to touch the Print to PDF export path any more, I'm closing this. The core idea is implemented for ODT.