What's your On-Device proofing workflow now?

Question

What's your On-Device proofing workflow now?

(Apologies, I have no recollection of why my forum name is a random string of letters).

Hi,

I've been publishing Fixed-Layout EPUB graphic novels & photo books via the Apple Books Store for a little over 10 years now, and the workflow was pretty simple - all the authoring was done in an HTML / CSS focussed text editor, and when I needed to preview within the real viewport environment of iBooks / Apple Books / Books.app (I'll just refer to it as Apple Books), it was just a matter of:

Add (still unzipped) Development directory to Apple Books as a Proof.
Open the Book in Apple Books as a new window.
Select the iPad from the Devices button.

The book would be pushed to the device, and then any editing on the Mac, changing text, a CSS value etc. would update live on the iPad so long as it remained plugged in and Apple Books was running.

That workflow was fantastic - I had complete control over the code, I wasn't bound to any one editing application, and I could set the image quality exactly where I wanted it when saving out from an image editor.

So the workflow for every edit was:

Change an authoring file.
Save the change.
eBook is automatically updated on the iPad to reflect the change while reading position is unchanged.

As far as I can make out, macOS Monterey replaced the Mac version of Apple Books with a Catalyst port of the iPad version, which doesn't have the proofing and push to device workflow. So the necessary workflow seems to be:

(Delete the old proof copy from the iPad.)
Change an authoring file.
Save the change.
Run your entire eBook fileset through the specialised EPUB-specific zip compression, which isn’t the standard zip compression found in Finder.
Airdrop your saved compressed version of the file to your iPad.
Interact with a dialogue on the iPad choosing to open the file in Apple Books.
Wait for the file to be imported to Apple Books, and to open at the cover.
Manually page through until you get to the place where the change you wanted to see is visible.
While this is happening, the entire book (some of mine are hundreds of pages, and hundreds of MB in size) is being uploaded to your iCloud storage, unless you have a dedicated iPad that isn't using iCloud sync for Apple Books, so you have to make sure you have enough space in your iCloud plan.

...and that's for every time you want to test something, or try something - how many pixels should the radius of the rounded corner of that image be?

Pick a number, then do all 9 steps.

Too much?

Pick a number, then do all 9 steps.

Surely there's a better way than this? If anyone has any solutions, please I'd love to hear them - the official documentation for Apple Books hadn't been updated to reflect the new post-Monterey reality until I raised the issue with Publisher Support in October 2023, so they didn't even seem to be aware there was a problem.

Thanks,

Matt Godden

https://www.golgotha.com.au

Posted on Apr 2, 2024 3:13 AM

Reply

Answer 1

Apr 2, 2024 8:39 AM in response to blselkhbrbsfgwb

Oh, and things I've tried so far:

Running Apple Books in a Virtualised macOS instance from prior to Monterey, with the iPad connected to the VM - no go, the devices button spawns an empty menu palette, even though the iPad is showing up in iTunes or Finder, depending on which macOS version the Virtual Machine (VMWare Fusion) is running. Yosemite, High Sierra, and Big Sur all show this behaviour when virtualised.

On that note - I recall there is / was a bug in iBooks on Mac where if you had the system overall set to show scrollbars all the time, the devices palette would be empty, because the width of the device entry was intruded upon by the always-shown scrollbar. It would break to below the bottom edge of the menu, and therefore be un-viewable.

I'm not sure how to tell if that's what's happening, or if the push-to-device direct connection is a different thing to the sync connection, or if another virtualising solution, Parallels or VirtualBox would be able to make that connection work.

Reply

Answer 2

Apr 4, 2024 8:24 AM in response to blselkhbrbsfgwb

Further updates have revealed the process is not quite so byzantine, and may have been partially improved since I first started testing:

Step 4: seems to be unnecessary, as Books on iOS / Mac seems to (now) have the ability to load an uncompressed development directory that has only had the .epub file extension added.
Step 5: remains - your development directory needs to be manually airdropped to the iPad, where it is not identified as a Proof.
Step 6: again seems to have changed, perhaps proofs do not trigger the dialogue to choose Files.app, or Books?
Step 7 & Step 8: Updated books that are copied over replace the previous version, but don't show the updates, presumably due to Books.app caching image data, so you still really can't avoid having to manually delete books before you airdrop an update.

So the process for every update you want to check appears to be:

Delete old proof.
Save changes to Authoring files on Mac.
Airdrop development directory onto iPad's airdrop entry in Finder.
(Possibly) manually navigate though the book to the place where the change you want to check is located.

As opposed to the old workflow of:

Save changes to Authoring files on Mac.
Observe changes automatically refresh on the page on the iPad.

I really wish Books.app could get the non-cached live proofing workflow back, if it could load a dev directory via SMB or WebDAV, that might solve a lot of the current problem, without introducing the need to plug in cables, etc.

Reply

What's your On-Device proofing workflow now?

Similar questions