I’ve searched but couldn’t find any concrete details about using Custom Metadata within headers or footers when using Scrivener 3. It would be very useful, especially when compiling a short story anthology.
Thanks.
I assume this is not possible, as, whilst I’m able to ‘print’ the custom metadata within the body of a page, it simply won’t show in the header or footer … is there a particular reason why, if it can be compiled in the body, it can’t be compiled in a header?
— Peter
Headers and footers are section-based constructs, to use word processing jargon—not page-based, as you seem to be suggesting. A document must have a formatting section break added to change them, which causes a page break at the point of insertion. Sections are used to switch column layouts, headers and footers, numbering streams and so forth.
I suppose in the most very basic uses of Scrivener, where one only ever has one single file for one major section worthy of a page/section break, then the notion of having custom metadata driving headers/footers makes sense. But as soon as you get into more typical use cases, where a formal section may have three or five separate items (and thus three or five separate custom metadata settings), then it gets confusing. Keep in mind that several chunks of text may even fall on the same page, complicating matters further.
Thanks for getting back to me, and for explaining the intricacies.
As I do use Scrivener in that basic manner – one ‘text’ file per chapter, poem or short story – this seems like a limitation, but can understand that when people use more complicated structures (multiples ‘text’ files per chapter, etc.) that it would become more complicated.
In the future, would it not be possible to create an ‘author’ meta-tag (with some primacy, and applied specifically) for different sections/files? As, when compiling a short story collection, calling the overall project author for the header is an irrelevant piece of information.
— Peter
It is I would say more a matter of whether it is worth the time adding mechanisms such as these (for which it sounds like would require a bit of complexity, in adding new user interface, settings in the compiler, augmenting the underlying project file format, etc.) to a program that is essentially designed to be a tool for an author to write the initial first-draft text toward some manner of work. Curators of anthologies and such fall a bit outside of its main remit, and on top of that, any kind of particular publishing detailing like this is also outside of its scope, is what I’m getting at.
More pragmatically, the general advice to transition the project to a desktop publishing environment, once it is appropriate to do so, applies here. Scrivener was never meant to be a “book making tool”—if it were, I think your request would be entirely more congruent. But I think if it were that kind of software it would look entirely different, perhaps working through more traditional desktop publishing metaphors, than a kind of “fill out the form and generate a document” approach, like the compiler is. The compiler has an effective complexity limit in how it works—i.e. imagine all of the complexity of InDesign (or even Word) packed into the Compiler, and in all reality probably made more complicated than InDesign since that at least allows one to design a book in a visual canvas-based environment rather than through a generator, where one must pre-configure all of the detailing and then “compile”.
In short: while the idea itself isn’t crazy complicated or impossible to think of ways toward implementing it, it does fall over that “line in the sand”, where everything beyond that point is better described as out of scope feature sprawl.