inheritable custom metadata

It would be amazing if the custom metadata could be inheritable by a checkbox flag in the metadata settings. This would make a custom metadata element available at all times regardless of include in compile settings.

Meaning if you define a custom metadata item like “SeasonTitle” marking it to be inheritable, then fill that in for a top level folder, all other folders and text documents under that folder would then have that metadata “filled in” with that value unless it is overridden in a lower document/folder which would then be used for documents below that point.

It would also be nice if the “include front matter” could have a “designated top-level folder” to also pull in those values.

This would allow things like:

Page headers or the title page to use <$custom:SeasonTitle> without having to set that value on every single document. Right now you have to use copy/paste in outline mode and manually set such items across the board.

This would allow compiling individual season episodes to separate docs getting a properly updated title pages and page headers or data inside of the text itself.

Expanding on this thought, it would be equally amazing if custom meta-data could be populated into a document! Entering placeholders into the document, <$Customer_Name>, would allow the document to be populated at compile time by pulling the associated key value from the meta-data list.

I’m aware that the Replacement feature of the Compile function accomplishes this as well. The difference being that this method requires the user to set the replacements with each new document. Following my example, the definitions could be built into a template and the key values defined as part of the document creation. At compile time the key values would replace the meta-data tags and the document would be completed.

Disclaimer: the following mostly applies to the Mac version only at this time, so when I say we already have a design for this, I mean the Windows developers are working toward a method that already exists, but diverges from how you’d like things to be, as described in the request.

So as to the original request, there are no plans for anything of that nature, but as described below there will be mechanisms for extracting information in a non-linear fashion as needed. This will more than suffice for most of the things you are referring to, and with an approach that has far less GUI overhead to learn.

I don’t think it would quite do everything you’re thinking it would, there are other complications to consider that make all meta-data usage in headers and footers problematic, regardless of whether that meta-data arrived via inheritance, bulk assignment, individual labour, Replacements, etc.

Page headers and footers are not something you can just freely print whatever up there at any point you desire. They require formal section breaks, which act like page breaks as well. Besides, given the way Scrivener is designed it isn’t really compatible with the notion of having individual documents doing anything with the header/footer. You might be using a file in the Binder as a single section, and so that concept would make sense, but it’s also possible to use the program in such a way that several hundred files to hold the content of a single section—which one of those sets the header? Generally the answer to that is very simple: the first chunk (often a container like a folder) which is also responsible for cutting to a new section / page break. So that is how things are designed: you have a general placeholder, <$sectiontitle> which prints the name of the last Binder item that caused a page break. And that system, although it doesn’t address every single possible thing one can dream of doing in Word or InDesign, does work for the vast majority of what people need of headers and footers—and that’s good enough for a program like Scrivener.

All forms of meta-data can be printed in the document through the use of placeholders (a list of them is found in the Help menu). For example <$label> does just what you might think it would, and so does <$custom:Customer_Name>.

Furthermore, the compiler will make use of Scrivener Links when they have been added to a placeholder tag. If you select that custom placeholder tag and link it to another document, it will print the customer name assigned to the document you linked to, rather than the file you typed the placeholder in.