I’m developing a workflow for outlining as discussed in this post, but when compiling for either Pandoc (DOCX), TXT or Markdown, this happens for both my chapter titles and scene titles (even if uppercase is chosen for both title and prefix):
Chapter ONE - Section Title
The expected output is this:
CHAPTER ONE - SECTION TITLE
Disabling uppercase in the compile settings seemingly fixes this issue, but I want all my chapter/scene headings and titles to be uppercase.
Thanks, I’ve moved this over to the Scrivener for Windows section as a bug, since it clearly does not seem to be reacting to these settings when using plain-text output (whereas it does seem to work with other formats). It doesn’t look like we have that written up yet as an internal ticket, so I’ll do that.
As an aside, as a Markdown user I most often handle formatting and numbering entirely at the stylesheet level, rather than baking it into the text itself with compile settings. It depends on the kind of file you are converting to of course, how that would be done, but even CSS can do all of this, for example, inserting "Chapter two - " into <h1>Section Title</h1>, and then transforming the case to upper. So that’s a potential workaround for any file type that can do such things.
I would imagine Word with DOCX can do so—LibreOffice certainly can if not. With Pandoc you can even set up the numbering and formatting into a template and set the compile command line to use that template for the output and get the result you want in one shot.
Depending on what type of file you are converting to with Markdown, you generally won’t have much actual coding involved, fortunately. LaTeX can get pretty intense if you can’t find a good stylesheet out there that does what you want (thankfully, with decades of volunteers contributing designs and such, you often will). CSS is pretty simple, but can be bit more like coding for setting up counters and incrementing them (though honestly it’s not much different than Scrivener’s placeholders once you transpose the syntax being used; for example, counter-reset: counterName instead of <$rst_counterName>, which is honestly even easier to understand than Scrivener).
I don’t actually have anything readily accessible at the moment that would demonstrate part/chapter/section numbering in CSS, but I do have this write-up on building custom enumeration. If you scroll down to the bottom of that post you’ll see how counters can be named, used and incremented, as well as how text can be inserted with the content attribute.
But for DOCX? You’d just be using the word processor’s native style tools. Here’s a brief description of how to do that, and plug the settings into Scrivener. That’s a good thread to skim as well, as it touches on some of these very concepts. Even if you do decide to stick with Scrivener’s numbering, as they did, stylesheets can still handle the uppercase problem themselves. I just figured I’d mention that (in LibreOffice anyway) you can keep the output more agile, rather than having the letters “T”, “W” and “O” printed verbatim into the text itself. I’ve personally never cared for “hard coding” documents like that!
Nobody will ever disagree with that statement! I do use it quite a bit (the user manual PDF is a LaTeX production), but mainly because I’ve been writing with it since the late '90s (and back then that meant typing it all out by hand in a coding editor), so it’s kind of the devil that I know. Typst is an upcoming alternatives for those that don’t need all of the wild stuff LaTeX can do, and you’ll find some good templates and guides in the Markdown area of the forum. I’ve given serious thought to transitioning to it gradually. It’s still maturing, but it looks to be reaching a point where it can handle the kind of design freedom I am accustomed to.
I don’t know if that’s easier than DOCX though—I guess it would boil down to experience. For me, trying to use a word processor is a million times more frustrating than learning an entirely new programming language, never mind a typesetting markup system.
Have you tried LyX? That’s what I messed with a while ago.
I make 90% of my .docx files in Scrivener, but fine-tune it in Word (because Pandoc can’t produce PDFs without LaTeX) to produce a PDF. If LaTeX were easier to use I could’ve done my dissertation faster xD
Have you tried LyX? That’s what I messed with a while ago.
Oh yes! In fact my very first NaNoWriMo attempt was written entirely in LyX. I still do keep a copy around, but since most of my .tex files are produced by either MultiMarkdown or Pandoc these days, I don’t have much use for it. I rarely ever “see” the LaTeX itself. If Markdown isn’t generating it, then Scrivener is, via its styles and section layout systems. What little I do use are overrides here and there, to cut to a new page to avoid an awkward paragraph break, or force a word wrap where the justification algorithm struggled. So the compiled .tex is often 100% ready to go to PDF, and I don’t need something in the middle, like LyX to do any extensive revision.
But yeah, definitely check out the Pandoc DOCX reference file workflow. Once you get the wiring set up your compile format you can forget about the command line, and do all of your formatting tweaks to the .docx file used to generate your output. I bet you could do away with almost all of the post compile fine-tuning.
I’d be down to trying LaTeX again, but I’m scared about disk space requirements hehe.
On my experiments, I discovered you could make PDFs directly from Pandoc (using PanWriter + LaTeX), but since I don’t really know how to get Pandoc to do a TOC, I stopped using it.
Also, @AmberV: does this letter case bug exist on Mac? While I do have a Mac, it’d be a pain to get it out to test (poor thing is dying). Just want to confirm
No it does not, it will follow whatever instructions you give it (in any of the three dropdowns in this tab).
On my experiments, I discovered you could make PDFs directly from Pandoc (using PanWriter + LaTeX), but since I don’t really know how to get Pandoc to do a TOC, I stopped using it.
I’ve never tried that, so I don’t have any specific tips, but in general there is a --table-of-contents command line argument that, if the target format supports it, will add them. That’s what we use in the ToC tab for Pandoc-DOCX output, along with the commands that adjust depth.
Um, Pandoc supports 12 different PDF engines, and at least 6 of them are NOT LaTeX or TeX variants — personally I’ve switched to Typst recently, a mostly wonderful experience, but I would consider a HTML->PDF workflow otherwise. I do still use LaTeX too. Another option is to use LibreOffice and the soffice command like soffice --headless --convert-to pdf input_file.odt after Pandoc runs and which can be automated from Scrivener (in my case using a script run via pandocomatic)…
I made a sample workflow that generates Typst directly (no Pandoc/MMD intermediate) or via Pandoc. I personally prefer to use Pandoc to generate Typst output (perhaps unsurprising ). You can customise the Typst templates that Pandoc uses, with Typst code being much more intelligible than TeX. There is also a free online editor so you can play with styling visually, really cool! Typst is still relatively new so new versions can bring some breaking changes, something to be aware of…
I do use it quite a bit (the user manual PDF is a LaTeX production), but mainly because I’ve been writing with it since the late '90s (and back then that meant typing it all out by hand in a coding editor), so it’s kind of the devil that I know. Typst is an upcoming alternatives for those that don’t need all of the wild stuff LaTeX can do, and you’ll find some good templates and guides in the Markdown area of the forum. I’ve given serious thought to transitioning to it gradually. It’s still maturing, but it looks to be reaching a point where it can handle the kind of design freedom I am accustomed to.
). You can customise the Typst templates that Pandoc uses, with Typst code being much more intelligible than TeX. There is also a free online editor so you can play with styling visually, really cool! Typst is still relatively new so new versions can bring some breaking changes, something to be aware of…