Inspired by an answer from @nontroppo in a previous thread of mine, I’m trying out something new, but I don’t know if it’d work. I’ll go more in-depth below.
What I’m Planning to Do
Just for fun, I’m using a Python script pipeline (that I’ve vibecoded myself) to create a fictional magazine (Rutan = Swedish for telly or screen) inspired by Radio Times. [1] The issue creator script is interactive, but I’ve thought about using Scrivener to create the issues (which would double my work speed) and then compile them into a .txt file so that the script can import it.
I’m using PrinceXML and CSS for styling too.
Ideas I’ve had to make this work
So yesterday I googled some stuff and arrived at this possible section layout:
In general, markdown metadata is specified per-project (one metadata block at the top of a single document[1]), not per section. Scrivener compiles to a single document, so if you want section-specific metadata this must be transformed into some intermediate markup and a custom filter could then use this when converting to HTML.
A simple solution is that section titles can contain attributes, and these attributes should make it to HTML and thus can be used. Scrivener would generate something like:
In this case the compiler section format can inject section metadata into the title attributes for that section.
Or you can use the compile format to inject custom “final” html elements with the section-metadata at the top of that section (after the title). There are many ways to cut this cake, as is usually the case for Scrivener / Markdown workflows.
if there is more than one metadata block in a document, they are combined together ↩︎
One thing to watch out for, with custom metadata in the Section Layout, is this open bug in the Windows version. Looking at my notes on the matter, it looks like if you use the Prefix tab instead of the title fields, you should be fine, and as I note in the thread, that’s a more natural place to put this kind of stuff anyway.
Just do make sure to clear out the Metadata fields from the main compile overview tab, otherwise you’ll get doubled up metadata blocks, as it isn’t programmed to detect anything from the section layouts.
I found a way to do this using custom metadata and document templates and avoiding the Metadata checkbox. I compiled a test into.txt format, and it works fine, as demonstrated below:
Title: Rapport
Duration: 10
Description: Swedish news delivered in a quick and concise report. Presented by Linnea Bergman.
Here is a thread on this matter in particular, which may help. As you say, the Metadata checkbox itself is not terribly useful for this.
Speaking strictly of formatting, you do need the three dashes on a line above and below, like Scrivener would normally put into the .md file. I think empty lines within this block are okay, but I’d keep each row adjacent to be safe, like so:
---
Title: value
Duration: value
Description: value
---
MMD + post-processing in Pandoc, you can go to HTML or PDF via PrinceXML directly. I can make s simple project for you, but the principle is the same as my Quarto sample workflow:
This example shows a section with custom metadata in the Inspector: ID, Class, Attributes etc. and in the compile format prefix there is Scrivener placeholders to generate markdown :::{ attributes } – a pandoc custom div. In your case you could make a custom div or use prefix (as @AmberV mentions for the windows bug) to make a title + attributes.
I have a Python script that creates an HTML file and a CSS file based on a JSON file. I’m automating the creation of the actual issue using Scrivener. The idea is to import TXT files, get a JSON and then turn that into a PDF using Prince.
I do plan to move towards Typst in the near future (either when I have a new Mac/mine is fixed, or when Scrivener for Windows gains a scripting window in its Post-Processing).
Ah okay, I thought you were aiming for a Pandoc YAML metadata block. If not, disregard the above notes on formatting.
As an aside, I made a compile Format for producing JSON straight out of the compiler, that might be helpful, or more straight-forward than creating an intermediary .txt and then making a script to process that into JSON.
