Sometimes I am making formatting changes and want to quickly check the resulting PDF or EPUB - for example a title page that needs to look right.
This is a now multistep procedure, even if the options are remembered and just need confirmation:
Select compile.
Confirm options.
Confirm export.
Confirm replace file.
Open in application.
What I’d like is a quick way to do all this by simply selecting a new option: Quick Preview. What this does is use the remembered settings, export into a temporary file and open it in the default application.
Addtionally, I’d like this available from the context menu in the binder, so that I can select an individual chapter and quickly preview it.
A +1 from me. At least for my use case Scrivener’s programmatic markdown processing does not necessitate a WYSIWYG external tool at all, yet still benefits from quick iteration.
Anyway there is a workaround, given that Scrivener does remember the last state of the compile. You can simply automate the dialogs. I use BetterTouchTool to add a custom keybinding to Scrivener (and where I use CAPS LOCK as a hyper key) and [^hyper][b] to build my project quickly:
You can see this simply selects the menu and automates pressing enter with a delay on each dialog (BTT can also use images for automation, so it can find buttons based on their pixels, but simply automating the keyboard is good enough). I could run a script to open the output, or do some other post-build tasks.
kewms: But I really, really like Scriviner! And I’ve paid for a license! A little tweak like this will make it even better for me.
As for “reaching a point”, I don’t work in a “waterfall” way, with all the writing done for ever and then the problem is output. I write a little and see if it the outcome looks the way I can respect. If it doesn’t then I might have to tweak some formatting options. Better to do that early and avoid a “big bang” later. So for me the turnaround time of tweak-and-test is important, a little like the debug cycle in SW development.
If I had ignored the output when I was investigating tooling, I probably would have gone for Reedsy and then only after months of work discovered that I couldn’t produce a copyright page to fit my needs.
Compile: disable replace (note, I posted a Keyboard Maestro macro to this one, for Mac users. I believe there may be an AutoHotKey script for Windows users floating around as well, but I don’t have the URL in my notes).
But as an aside on ePub, when I’m doing fine tweaks like that I do them in an ePub editor, such as Sigil. Such changes appear in real time in the preview pane, and so I can very quickly get a look I like, and then take what I changed back to Scrivener, doing one compile to confirm it worked the way I expected.
This is the approach I take for almost everything. I compile once, and then revise and tweak on the intermediary or final file, making the change in Scrivener as I go. I typically at most only compile two or three times for what would probably be dozens of compiles if I didn’t work that way. Why spend accumulated hours waiting for compile when most editing environments provide real-time feedback? And if you’re reducing how often you compile, then things like confirming overwrite become far less of a point of friction.
For PDF I can’t really help you there, except to say you’ll get a better result by creating PDFs from other programs anyway (where all of the above applies), so that’s a bit of an awkward one to begin with.
