Hey all. We’ve been happy with the Scrivener as the writing tool and also as the layouting tool to produce final PDFs. After installing 3rd party spellchecking for Finnish language it got even better in macOS.
Now for our second book we would need a bit more layouting than Scrivener can provide, although all the basic text and structure PDF output will be fine. I’m trying to automate this post-processing as much I can, but I noticed the post-processing scripts settings are not available for PDF formats.
Any specific reason not to be able to run PDF through post-processing? I can run processing manually, but would be nice to configure it into the PDF format.
I have custom python script to open up the generated PDF and an additional overlay PDF file made in publishing app, and these are then combined based on specific instructions (scanned of from the page content). Mostly as image based full page images and such that are not easy to layout in Scrivener (image through external file tag could not be scaled past the margin area). Doing manual post-processing in publishing app isn’t practical with iterative workflow when the page order or number might change, but you would still want to see final product as soon as possible.
I tried to look other ways, but all the “traditional” publishing workflows seem to think publishing as final manual stage put to stone and if you need changes, redo everything or copy manually or typo fixes etc. Or then all layout needs to be done externally.
Another related to this was that Scrivener PDF format pages don’t have Bleed settings. I had to set the actual page larger by the bleed amount and then increase the margins as well to emulate this.
I do what I think you are trying to with Hazel. I direct the PDF to a specific folder watched by Hazel, then Hazel detects it and does it’s thing as instructed. Hazel can be setup to call other scripts/apps, including Python scripts (via a shell script), plus so many other useful things.
You can do similar with macOS Automator so no problem and easy to make the python script more of monitor script for file(s) and open the output pdf in viewer after done. Was just looking for the existing feature in Scrivener to hook into and didn’t see any reason why it wouldn’t be possible, thus the wish for this.
Generally speaking, the PDF format is designed to be final output, not an intermediate step. It’s difficult to make any changes beyond the most rudimentary edits.
The Compile command does support adding crop marks to PDF files. It’s the Add printer marks option in the general Compile settings panel. You can also set the bleed for the cover image, but not for arbitrary pages.
(Note that full bleed images are uncommon in books outside of covers because they are difficult to do on a conventional press.)
The press specifically asks bleed on full PDF (all pages) if there are any full bleed images needed on any of the pages. Also specifically no crop marks are to be visible, only the bleed area. So format is same as for covers. Press is digital on-demand printing.
I do understand the PDF to be “final” output, however it’s no problem to edit it afterwards with apps, or in this case programmatically. It is relatively easy, with some restrictions. In this case the mentioned merge of external PDF content to specified pages to construct the final finished PDF.
That makes sense. They’re effectively making the page size bigger for the whole book in order to accommodate the bleed. And for print on demand they’re probably sheet-fed, rather than web-fed, which makes using different paper sizes a lot easier.
Just update on this. The Python post-processor (custom tool now called Fuse PDF) works fine. I didn’t yet see how you could add app to the pdf-extension files as one of apps Scrivener would open with, so the tool just has now a monitoring watcher that it does it’s job whenever the specific PDF file is updated by Scrivener compiler. After that it just opens it for preview same way as Scrivener would.
I might release the tool at some point, but for now we’re testing it on our own workflow and see, if there is something to improve. Right now it scans the compiled PDF for specific fuse-tags which link to PDF file and bookmark/ToC entry. Those files are prepared in Affinity Publisher (Anchors to name pages). In processing phase the tags are removed from the content and “fused” with the external PDF content. From Publisher you can easily make spread images with bleeds and these can be properly fused and split into the spread pages.
This allows for full-bleed content for Scrivener compiled PDF with continuous workflow. Also for preview purposes it allows trimming of the bleed, so the book will look as-printed in the Preview app if using the two-page browsing mode.
Little bit unrelated problem arose with the section layouts settings for “Always start on section on: recto/verso”. I tried to test it with blank project and it seemed to behave right, but with our project the Scrivener compiling begins to insert blank pages into middle of section text and sometimes even multiples of them. Definitely feels it begins bugging at some point. Probably need to trim the project into smallest version it is still behaving incorrectly to understand what causes the problem. Now only way to fix it was to manually add blank_page where needed.
Regards the “start section on” paging problem. Still investigating, but I was able to pin at least one problem with the inline page-break you can insert to your text. Probably should split text to different documents instead - however:
The inline page-brake -character position is incorrectly parsed. The page break happens from the begining of the wrapped row flow where the break is inserted. To overcome that bug, you should always have newline inserted before the break character. I was wondering why some of the text was lost and noticed it was transferred as “hidden white” text to the next page while it should have stayed at the previous page.
The the another bug (or feature?) regarding the “start section on” happens with the inline page-break. The section text after inline page-break is considered as “new section” and it forces it to start from the recto/verso even though it should probably still flow as current section.
I have to see if we had some page-break inserted or if it’s still some other flow bug.
Just to recap here. The new custom PDF tool works great as described. We got our hands on the actual hardcover books yesterday after some delays in the printing side. Looks good and we are happy with the quite fast continuous delivery workflow to see the final layout with all the elements done outside Scrivener. Feels as if Scrivener was doing the processing.
In the image above the photo page and the title script text is externally “fused” to the Scrivener exported PDF.
As side note, the PDFs were delivered in PDF/X-4 format (tool changes the format) with bleed included, and images set to 600dpi. Transparencies were properly printed at least in this case with the digital printing. Also full bleed spread images were successfully printed and alignment was good.
