Second Covid shot this week, and it hammered me for most of the rest of the week.
I’m calling the Surfing The Deathline – Full Course cover complete with this final set of tweaks.
It only took decades, but I’m finally happy with the way I draw these characters.
I spent some time playing with the setup of my Fastspring store, and continuing back-and-forth with a friend who’s experimenting with building a tool to enable EPUB books to be updated after purchase. If we can get that working, we’ll close the loop on the entire purchase and update cycle for indy comics / books publishers.
Some administrative stuff this week – pushed an update of Surfing The Deathline to Apple Books, and made some progress on trying to get my head around Fastspring.
The updates for Surfing The Deathline went badly, as Apple is continuing to us a black page template for my uploaded books, and putting the cover graphics onto it in such a way, as to, well see the following image:
So they’re making my covers look like muddy garbage, and while “engineering are working on a solution” and have been for months. There’s a 10 second fix to their site’s CSS that will mitigate the problem in the meantime, but Apple won’t make it.
Had an interesting email exchange with folk from a European agency that produces technology for EPUB books, about whether they’d be interested in creating a delta upgrader to allow customer-side patching for EPUB books, so a publisher could just issue an errata .zip file, and a tool at the customer’s end could run a patch process against the file, to replace the old assets with the new ones. The upside of this is it lets book sellers offer free, or sell paid upgrades / DLC of a book in a way that means they don’t have to issue a whole new book, or manage customer accounts.
They were interesting discussions, but even more interesting was a conversation with an old friend, who’s interested in trying to build this tool himself, as a “just to see if I can” project.
First Covid shot done. After complaining on the morning of the appointment that one of the downsides of adulthood is that no one gives you a lollipop after you have a vaccination needle, I received my injection, and was sent to the observation area…
…at which I was directed to take a water bottle, a lollipop, and to have a seat.
See, there are some upsides to a nightmare plague that’s killed untold throngs of people.
Other things, I bought a couple of old refurbished Xbox 360 Slims, for LAN coop gaming.
Lots of futzing about with medical stuff – getting MRI scanned, and organising a Covid vaccine appointment in a couple of weeks.
Work on Surfing The Deathline continues, with slow finnicky changes to provide a final polish. It’s boring work, but I don’t really begrudge it, as it’s stuff I needed to do from the start, but just didn’t think to do.
This week, I got the EPUB production process fully sorted. There was a lot of time going back though the book, making changes, unmaking changes, and generally fiddling to get things to a point where I’m happy with locking them off, given moving off the Apple Books store will mean books won’t be easily updatable.
What I did discover is that a quirk in the maths for rasterising the .pdf file to an image (in this case tiff), means that by increasing the dimensions by ~20px, the rendering time is cur from ~8seconds to ~1 second.
Installed a new external Bluetooth antenna into my old Mac Pro, which seems to be alleviating the problem of my keyboard & trackpad losing connection through my desk.
Spent a bunch of time learning how to install a commandline image processor, after discovering the Apple built-in one doesn’t actually get the math correct on image scaling.
It’s a terrible dilemma – the Apple one can process all 236 pages of my book from PDF to PNG in about 3-5 minutes. Photoshop requires 35 minutes to do it – 10 times as much.
I’d hoped this commandline option might be faster, but alas, it requires a LOT more time – almost 2 hours for the full run.
So, back to relying on an ancient copy of Photoshop.
Other interesting issues, while going through Surfing The Deathline, I discovered a whole bunch of errors that have been in the published work for, up to 15 years. It’s baffling how blind you can be to your own work.
So here’s an interesting mystery / conundrum / process I recently went through in trying to create a new workflow.
For reasons or not wanting to subscribe to software, I’m still using the CS5 versions of Adobe Apps for Surfing The Deathline. The original documents are heavily constructed in Photoshop, then all the text, sound effects etc are done in InDesign, which makes them rather non-portable to other solutions.
It had been so long since I’d done a serious update of the books, that I’d forgotten parts of my workflow, and so had started some things from Scratch.
Surfing The Deathline uses .png format images for its pages. Although they take up a lot more space than .jpg versions, they have an advantage of being colour-accurate. A major problem of .jpg is that for images in black & white, a single pixel of colour will shift the white and black values away from their correct tones. So, where you get two pages butting up against each other at the spine, the greys might not match.
InDesign CS5 has no direct png output option, so the workflow is:
PageExporterUtility script to output the pages as individual .pdf files
Convert the .pdfs to .pngs
rename the .pngs and move them to the appropriate EPUB document’s image directory.
I had created an Automator action, which took in the .pdf files, and converted them to .png, and saved them to disk. It took about 3-5 minutes to do all 236 pages.
But there was a problem with he output…
Certain pages, seemed to have red & blue fringing on their text. Going through the .pdf files, it bcame apparent that it was linked to the pages which had a specific masterpage controlling their appearance. Looking at that masterpage, the thing that suggested itself as problematic, was the page number – it was frontmost in the layering stack. So, I deleted and recreated the page number object in the masterpage, applied it to the pages, and reran the .pdf to .png workflow.
Problem solved. Almost.
My large sound effects were still showing red/blue colour fringing. After a couple of days research, it became apparent that this was caused by the system applying sub-pixel antialiasing to the .pdf file during the render.
After experimenting with commandline options for disabling it, I found out there was actually a checkbox for it in the System Preferences app. Unfortunately switching it off makes the system’s display look worse, so what I needed was a way to toggle it off, run the image processing steps, then switch it back on.
After some experimenting, and asking on forums, I was able to get an Applescript that did the job, and add it to my Automator action:
What this does is:
run an Applescript to open System Preferences, test if the checkbox is ticked, untick it if it is, close System Preferences, then,
run all the pdf files through the Render PDF Pages as Images function to create png files, then,
move the converted versions to a new location. Then,
open System Preferences, test the antialiasing setting, and switch it back on, then close System Preferences.
It was fantastic – I had a wonderful system that, once I’d output the .pdfs from InDesign, could after selecting all of them, render them all to .png in a single right-click.
But there was a problem…
Images which crossed the spine of the EPUB book weren’t aligning correctly. Clearly, something was wrong with the way the Automator renderer was converting .pdf into .png. It didn’t matter what scale I rendered it at – even at the full native 300dpi, the problem remained.
When I compared it against doing the same process manually in Photoshop, it also became apparent that the math behind Automator’s conversion was out – files were always cropped 1-2 pixels smaller from Automator, than they were from Photoshop.
Then I started researching if there was an alternative commandline image processor in macOS – something I could call from an Applescript, to replace Render PDF Pages as Images. Thankfully, there was – SIPS, Scriptable Image Processing System.
After a bunch more research, I managed to sort out the appropriate commands, and gave SIPS a go on my pdf files. The results were the same. I tried it manually with Preview, the results were the same, again. It appears SIPS is the core image processor all these built-in macOS tools use, and it’s SIPS that has the bad math function for rendering PDF files as images.
Sips also produced pretty garbage image quality, compared to Photoshop.
So now I was looking for an alternative to SIPS, and I managed to find one – ImageMagick, a cross-platform commandline image processor. It uses Ghostscript, an opensource alternative to Postscript to render the .pdf, so everything about it will be separate from the SIPS processes. After a couple of days trying to figure out how to install it (hey, opensource projects, try making your basic documentation an educational resource for people who haven’t used your tools previously), I was able to make it work…
It delivered fantastic results, but took 30 seconds per image to process the .pdf files. In contrast, Photoshop, which was so slow I was looking for an alternative, takes 8 seconds.
You might question why I don’t use Affinity Photo, which can tear through the entire 236 pages in around 8 seconds total (gotta love that multithreaded action). Well, unfortunately, Affinity Photo’s pdf renderer can’t handle the edge effects of my InDesign speech bubbles.
So I’m back to where I began, using a ancient versions of Photoshop and InDesign, and needing to take a 35 minute break so Photoshop’s Image Processor script can do its thing, every time I want to run a set of updates from InDesign to EPUB.
Update 23 April 2021:
In experiments with image sizes for Photoshop’s scaling when it renders the PDF file to TIFF, I’ve hit upon a target size that seems to be in some sort of mathematical sweet spot for Photoshop, because the processing time has gone down to about 1 second per image, from ~8 seconds.