The default mode of operation in Scrivener does not presume that one wishes to form one single sentence from dozens of documents. So there is no straightforward way of putting elements from multiple items onto the same line.
Another problem with using Separators is that if an item has no other content to print, then it will be ignored. Since you’re solely looking to export the custom metadata, that means nothing else will be printed for the item, and since the request to print the metadata is hinged on whether or not the item has content, nothing happens. So a better place to do this is in the Section Layout’s prefix, which will always print, even if the item otherwise has no content scheduled to print.
When setting up multistage adjustments like this, I think it it is best to test compilation at each phase so you can see what is happening, and how it consequently works when all put together, as well as make adjustments in how you are doing things:
- In the Section Layouts pane, select the layout that should print items in this fashion, and click the “Prefix” tab. Type in your placeholder tag, followed by a string of characters that should be unique. Here is an example:
<$custom:NameOfField>@@
- Verify that the Separator settings that apply to these types of items use a simple “Single return” in all cases. We don’t want extra carriage returns getting in the way of anything. The opposite is true of any other type of content you are inserting—like section titles. You want to make sure those have at least one empty line before them, so that the replacements we add won’t combine heading lines with metadata lines.
Run a test compile. You should be seeing one line for each custom metadata entry, with the “@@” text at the end of each line. Lines that represent items that have no custom metadata will consist entirely of “@@”. So we have two things to look for and handle.
- Let’s get rid of the empty entries first. In the Replacements pane, add an entry looking for the following search pattern:
^@@\n
Leave the With field blank, and check the “RegEx” box. This will look for lines that begin with the code and are followed by a carriage return. Since all three characters are part of the search pattern, replacing them with nothing removes not only the code but the line itself.
Give that a test compile. If you’re like me, you put a binder item at the very end that has no custom metadata. This points out a unique problem in that the last line in a text file doesn’t have a carriage return, meaning the Replacement that looks for the above will not see it. To fix that, go into the Text Layout compile format pane, and simply add one carriage return to the Document Suffix.
- So at this point you should have a file that prints one line of metadata per item, and any items that have no metadata are entirely omitted from the output. If you have sectional headings those should be fine as well. Next, we need to get rid of the markers on the ends of lines, and combine them with the following line. Add a new row in Replacements:
@@\n
For this one, replace the contents With a single space, and again tick the RegEx checkbox. It is important that this replacement come after the one we already created. Replacements are evaluated in the order they are listed, and this second one would mess up those lines the first one is trying to fix.
Do another test compile. You may notice that the heading lines are now directly adjacent to the last line of metadata. That’s because the spacing line added to them is removed by the above replacement. The easiest solution is to change the separator for heading elements from “Empty line” to “Custom”, and inserting one carriage return (using ⌥↩ in the text field). Why only one? A custom separator comes with a free return to start with (after all we wouldn’t be here otherwise), so adding a custom separator that is a carriage return results in two of them—one of which is removed, leaving a clean single empty line above headings.
Of course with formatting you could use other techniques such as font size, paragraph spacing and so forth. The technique of using two returns is more important for .txt.
The attached project demonstrates a working example of the above steps on some sample data.
single_line_metadata.zip (75.8 KB)