Many users have specific needs around the post-processing of generated PDF manuscripts, such as adding watermarks, compressing files, or applying other treatments. Currently, I use command-line tools to modify PDFs of my manuscripts after compilation in Scrivener (e.g., using a script to add a watermark).
Given that many third-party tools effectively handle features that may be missing in Scrivener, I propose a new feature: the ability to specify a custom command to be executed automatically after a project is compiled, referencing the generated file. For example:
This would allow advanced users to integrate external tools like PDF Toolkit directly into their Scrivener workflow, streamlining tasks such as adding watermarks, compressing PDFs, and more.
Additional Suggestion:
Cherry on top would be to allow users to save multiple custom commands within in the general Scrivener settings. This would enable users to select which command to execute based on the selected compilation format (e.g., choosing different scripts for different output formats like PDF, DOCX, etc.).
This feature would provide flexibility for advanced users, enhance Scrivener’s utility, and leverage the power of existing third-party tools – Thus offloading a lot of feature request to integration wth 3rd party utilities.
You mean… like “24.22 Processing” in the Scrivener manual?
Using the post-processing capability, you can have Scrivener send the compiled source document to any utility capable of accepting data and arguments from the command-line shell, including your own scripts.
Oh, I see. That would indeed be convenient. I haven’t used Scrivener to generate the PDF output in a while, so it wasn’t obvious how you’re approaching it.
I should’ve been clearer. Also since we’re in the subject. If there was a command line from scrivener that would actually compile a project without the needing of opening Scrivener, than it would be even more powerful. This is because we could then pipe the resulting file into another command line tool.
But if you didn’t modify the project’s content (in Scrivener), why would you need to compile it (again)? You know what I mean…
Either Scrivener is already open (because you edited something), and then you can already simply compile or initiate an elaborate post-processing chain right from the Compiler, including PDF generation in the Terminal. Or not. In that case you likely still possess the last compiled (or “raw”) output and there’s not need to involve Scrivener. Maybe I’m overthinking this.
+1 for post-processing for all outputs, there are many use cases to improve workflow not only for PDF but other outputs too…
As a small side-note, many use cases for markdown or plain text do generate PDFs (the text is an intermediate, for example Scrivener’s LaTeX template uses plain text but generates PDF output), so technically Scrivener’s post-processing can automate PDF customisation. But you need to switch to use text as an intermediate + PDF engine for that workflow enhancement to apply.
As as stopgap, you can use file or folder watcher scripts to trigger post-processing. On macOS this is built-in using launchd, there are several 3rd party commandline tools, and I’m sure on Windows there are solutions too.
But if you didn’t modify the project’s content (in Scrivener), why would you need to compile it (again)? […]
Say that I have a few beta readers for example, and I want to add watermarks for all of them. Some will also follow a different format (proof copy vs manuscript). I could have a script that would produce multiple copies with different watermarks.
While I do believe that Scrivener could benefit from built-in watermark feature for PDFs (it has been asked here before), I can see how this specific requirement is an over-stretch. So off-loading to 3rd party tools would be the way to go. With a CLI tool from Scrivener, it would be the cherry on steroids at the top of the cake!
Oh, I get that part. I just fail to see what Compiling via command-line parameters would change (since Scrivener doesn’t watermark, but also in general).
But yeah, I won’t argue against a post-processing setting for all formats.
Ok so picture this: I want to create 20 PDF outputs. Each one of them should have the name of the beta reader plastered as a watermark on each page. Some of these are formated in manuscript modern. Some in manuscript courier. some are final proof.
How would you do that today with Scrivener and how long would it take?
With the example I gave, that could be done in seconds, not minutes.
I could have a text file that contains the names of beta readers. A shell script would parse this file and execute the scrivener-compile executable for each case, then piping the output file to a 3rd party pdf tool.
Now picture all sorts of complex user requirements that Scrivener just managed to enable by offloading it to third party tools with this feature.
About zero seconds. I wouldn’t do it in Scrivener.
Okay, to be fair, I would still compile it once to MMD, that’s not zero. But you can automate everything else, the PDF generation, the watermarking, which users gets what format, and possibly even email it to them. Of course you have to set this up once. But you have to do that anyways.
(Basically the other way round, not launching Scrivener 20 times, but Scrivener launches your script once and that does whatever based on your user “database”.)
Ok. So I need to look into MMD then. Haven’t used it. I’m curious to read more about Scrivener support for markdown (reading this) as well as @nontroppo’s pandoc documentation.
Almost anything that you might want to do will be done more easily before generating the PDF than after. The PDF format, by design, is notoriously difficult to edit.
Just to quick summarise, most of us don’t use markdown directly when writing, but use Styles and Section Types that are a core part of Scrivener’s writing environment. The magic happens in the compiler, where Scrivener translates these Scrivener features to text markup, then the post-processor does its magic to do whatever you want. You are not limited to PDFs either, keeping output flexible. It can be a bit overwhelming when trying to come up with a workflow…
For PDF output you have a large number of engines available: Pandoc - Pandoc User’s Guide — the standard is LaTeX, but my current crush is Typst (accepting this is still a young project at V0.11 and will change as features stabilise), and if I wrote fiction I would also contemplate PrinceXML.
You know what I mean…
