So this is a project I’ve been working away on designing for a while now, as a way to solve a lack of accessible studio space, and the need to stay at home during Covid social-distancing.
It’s a trifold-door cabinet, with internal power supply, that will be installed in my carport, between the secondary entrance (left) and laundry (right) doors of my home. It’s designed so that all the equipment stacks inside it – at the rear is workbench space, including a drill-press station, then the UV-blocking welding screens go in front of that, and finally the welders on a trolley, and a fold-up welding table.
All the equipment within is on wheels, so it can be rolled out and the space configured, with no lifting required. All it requires me to do is move my car forward a couple of metres, but the cabinet is narrow enough that my car can fit beside it when closed.
There’s a long, narrow workbench for my drill-press and bench-grinder, as well as storage, and a table for my metal-cutting bandsaw (a quiet alternative to a drop-grinder), that sits over the Air-Compressor. The compressor is an interesting piece of kit – it’s a silenced model, that uses two small motors, rather than one large one. You can easily hold a conversation at normal speaking volume, while standing next to it.
The power supply, which will sit roughly in the middle of the cabinet, is already installed – a pair of 15 amp, and a pair of 10 amp plugs, on a 32 amp line, so I can drive both the air compressor (10) and the welder’s plasma cutter (15) at the same time. Or, I can keep both my TIG and MIG welders powered up at the same time, and alternate between them, using MIG to tack things in place, then TIG for the finished welds.
All in all, it should be a super adaptable, and quick setup / packdown low-effort workspace.
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.
Lockdown again for Brisbane, and once more, we cower, waiting to see if the holiday-refugees and second-housers will try to escape the dome and bring their plague to us. Thankfully the state government & police seem to be pretty upfront in saying people aren’t allowed to escape, and the local mayor & accomodation providers are cancelling bookings, in an effort to save Easter.
But this is Noosa, so none pays attention to mask rules, etc.
My dental and optical sagas continue, it’s a never ending fight to get some pretty simple healthcare here. Sometimes I think the local providers are just set up to coast old people to the end, rather than provide significant care.
The end of the week saw me solve a longstanding problem with my EPUB publishing workflow, which will be a blogpost in of itself.
Making progress on the cover art. As usual, I’m finding bugs in my tools – this seems to be a never ending thing, noone seems to make software that is well engineered enough to work properly when faced with an unusual system configuration.
This time, it’s ArtRage, my digital natural media painting software, that has decided all menus need to be offset, or rather need to be spawned a specific, set, physical distance from the UI element that is clicked upon to spawn them. Thus:
Spent a bunch of time working on the cover for Surfing The Deathline: Full Course. It’s been a long road trying to get to where it is, most of which was spent on an abandoned concept, of redoing Hokusai’s Great Wave in pill logos. But, it required extending the original image, and guess what?
Extending the masterwork, of a master of a artform is REALLY difficult. Whoda thunk it?
So eventually, I gave up, and, looking around in my folder of supporting art made for other things Surfing The Deathline-related, came upon an image I’d created aaaages ago, but kept on using as the background for the SDL website. Unfortunately, I’d forgotten how I achieved it, so most of the week was spent trying to get the right combination of filters on the original set of photos.
Once the background was done, there was the problem of what the “feature” artwork was going to be. It’s difficult, because every individual cover had already featured a main character (or group), and I didn’t want to overly emphasise or double-feature any of the major characters, given the focus shifts throughout the book – the ostensible “main” character at the beginning only speaks in the first two books, thinks only three words in the third book, and is silent for the rest of the series.
As is often the case, thinking the problem out with a pencil was the solution. I started doodling, and the answer built itself – the four main speaking characters, arranged as a lineup, with poses that speak to their personalities. The front cover featuring Eddie & Jan, the back, Blank and The Dealer.
Air-conditioning installer returned on Monday, to install a bunch of extra equipment in the roof, which has fixed all the problems we were having with the aircon system.
We can now set one room to be cold, while the rest of the house stays warm, and the inverter is only running occasionally, instead of 24/7.
Further, I’m still waiting to hear more about how the coolsuit suppliers are going to sort a solution to the failure of the backpack’s bladder. I suspect by the time it’s sorted out, it’ll be cold enough not to matter.
I also had yet another experience of being quoted on twitter again, by one of my favourite cyberpunk authors – Bruce Sterling.
Lots of digital stuff – some major breakthroughs made on converting pdf files to png for publication in EPUB format. The huge show-stopper problem that previously prevented me using the built-in macOS tools to do the job, has seemingly been fixed, unbeknownst to me, so I was able to get a whole bunch of stuff automated.
I managed to update all five parts of Surfing The Deathline, and get them live on the Apple Books store, but not without them screwing a part of it up, and applying some weird colour tint to the cover art.
What seems to be happening, is that for some reason, Apple has decided two of my books should have a black base colour for their cover art, as presented on the Apple Books Preview site. It seems the website works by having a basic tone texture for the book cover, and then applying the cover art to it in multiply mode, so the tone texture produces a subtle gradient on the image.
I can inspect the page source, and if I switch off the background colour attribute in this class:
Most of this week has been spent on digital processes – clearing up Surfing The Deathline for eBook publication. Primarily, to get one final update done for the versions on the Apple Books store, before creating the collected version for direct sales.
Highs and lows all round as options presented themselves then failed, but finally I’ve succeeded, and managed to get a workflow happening.
Had a moment of reflected glory – Bruce Sterling, one of the two founding authors of the whole Cyberpunk genre, Quote-tweeted me: