Like any craftsman, I care deeply about my tools, because without them, I can’t do my job. But unlike a carpenter or plumber, my tools change constantly, putting me in the unenviable position of having to evaluate each new version. Unfortunately, that’s impossible — I have to get my work done, not run test suites on every new version of my key applications. And while refusing to upgrade is always an option in the short term, it’s not something that can be put off forever, particularly if the new features and fixed bugs are important.
So this is a story of two problematic updates: how Pages 4.3 changed its EPUB export and how BBEdit 10.5 broke a key Automator action. More to the point, it’s a story of how two very different companies — Apple and Bare Bones Software — treat their customers.
Pages 4.3 Consumes Hours of Our Time — It all started when the time came to publish Kirk McElhearn’s “Take Control of iTunes 11: The FAQ.” We currently rely on Pages for writing, editing, and producing our Take Control ebooks. It does many things well, and we’ve been able to work around its infelicities and longstanding bugs (see “How Take Control Makes EPUBs in Pages,” 30 September 2011, and “Strategies for Switching from Word to Pages,” 18 January 2012).
When Michael Cohen started to export the EPUB file for Kirk’s ebook, he ran into unexpected problems — all our inline graphics for various buttons were way too large and not always in the right position — iBooks was particularly bad. This was unexpected, to say the least — we’ve been exporting EPUB from Pages for quite some time now and we’ve never seen anything like this.
Michael and Tonya spent several hours trying to determine initially if the problem was corruption in the file, but as they worked through various tests, they realized that even new files were showing the problem. After another few hours of work, Michael tracked down part of the issue — Pages 4.3, which came out in mid-December 2012, changes the way graphics are handled in the EPUB code. Previously, Pages used a SPAN element, but in 4.3, Apple switched to a DIV with directly applied CSS styles for
The next day, Tonya and I sat down with the EPUB code and BBEdit and figured out how we could use grep in a text factory to convert those DIVs back to SPANs. (Although BBEdit can edit EPUBs without expanding them, it can’t search across all the files in an EPUB without expanding it first.) That wasn’t too hard, but the results weren’t reliable. That was when I realized that Pages 4.3 wasn’t just writing different EPUB code, it was actually exporting different graphics than previous versions had done.
Here’s the thing. Because Pages is a WYSIWYG app with decent graphics tools, we sometimes resize graphics after importing them for optimal visual layout. It turns out that previous versions of Pages exported graphics for EPUB at the size to which they had been resized (as you would expect!), whereas Pages 4.3 instead exports graphics at the size they were at import and attempts to resize them using the
width attribute in the DIV’s style. It’s not entirely clear to me that this is possible, but regardless, Pages 4.3 does it wrong, which is why our inline graphics were way too large (and yes, I filed a bug with Apple). If it could be made to work, this approach isn’t inherently a bad idea,
since the graphics can theoretically then change size based on other variables in the EPUB reading environment. On the downside, the resulting EPUB was also vastly larger in size — roughly 18 MB instead of 3 MB — due to the larger graphics.
Regardless, we were in trouble, since even though we could munge the EPUB code, we couldn’t easily identify or modify the troublesome graphics. We knew by this time that Pages 4.2 didn’t exhibit the problem, but of all the Macs at our disposal, that version still existed on only one — Tonya’s MacBook Air. We also had a couple of older Macs (Tristan’s MacBook and Michael’s previous iMac) still running Pages 4.1, but we had upgraded all our production machines to Pages 4.3 back in December 2012 when it came out.
“How could you have been so careless with a key part of your production process?” you might ask. Remember how I said that it isn’t feasible to run test suites on every possible upgrade? Well, we foolishly believed Apple’s release notes for Pages 4.3 (as part of the iWork 9.3 update), which read, in their entirety:
iWork Update 9.3 adds support for iWork for iOS 1.7 apps.
You can’t even read between the lines to assume there were other changes, since there is only one line! And there’s no way anyone could guess that there should have been at least one more line reading:
Changes how graphics are handled in EPUB export.
So we all upgraded. Now we wanted to downgrade to Pages 4.2 (and support for iWork for iOS 1.7 isn’t important to us), but a restore from Time Machine didn’t work — the version of Pages 4.2 that came back from early December couldn’t save files and crashed whenever we tried.
Equally unsuccessful was reinstalling Pages from the iWork ’09 DVD and then attempting to upgrade it to version 4.2. That might have been more possible, except that Apple, for unknown and thoroughly unhelpful reasons, has removed the iWork 9.2 update that would upgrade Pages to 4.2. (Why? Why try to prevent what users might want to do in the future?) I was able to use this technique to get to Pages 4.1 with the iWork 9.1 update, but as with the Time Machine-restored version of 4.2, Pages 4.1 restored in this fashion also had saving problems.
Stymied, I posted to a private mailing list of highly technical friends, and was overjoyed when someone suggested the eventual solution: restore not just the
Pages.app package from Time Machine, but also the
/Library/Application Support/iWork ’09 folder, which contains a number of frameworks shared by all the iWork apps. I also restored the earlier versions of Keynote and Numbers, since it seemed likely that a mismatch with the support files would cause problems.
Though we weren’t keeping exact track, I’d estimate that Apple’s silent change to Pages 4.3 cost us 10–15 person-hours of work. Were we all being paid for our time, that would have been $500 to $1,000 of wasted expense, just to get back to status quo ante. And all because Apple didn’t see fit to mention such a significant change in the release notes.
That shows a profound lack of respect for customers on Apple’s part, and is particularly offensive when it comes to tools used by professionals. It’s bad enough when Apple causes normal users significant headaches, such as with the massive changes in iTunes 11, which cannot be downgraded to iTunes 10.7 (see “iTunes 11: The Features Apple Removed, and Alternatives,” 4 December 2012). But when Apple’s decision to conceal changes threatens one’s livelihood, it’s time to start looking at tools from companies who care about their customers.
BBEdit 10.5 Breaks and Fixes Automator Workflows — Those companies do exist. As a counterpoint to my experience with Pages, let me tell you a story about how the recent BBEdit 10.5 upgrade also caused me problems last week, and how Bare Bones Software’s transparency and solicitude toward their customers resolved the problem quickly.
BBEdit comes with a set of Automator actions, the most interesting of which for my purposes is the Search and Replace action, since it supports grep and thus lets me manipulate text in filenames far more effectively than is otherwise possible in Automator. I have a complex set of Automator workflows that I created to distribute finished Take Control ebooks, but when I attempted that with “Take Control of iTunes 11: The FAQ,” my workflow failed due to a file not being renamed properly. As I stepped through the workflow, I saw that the problem was in BBEdit’s Search and Replace action, so I did a quick Google search on “BBEdit 10.5 search and replace automator
The second result was release notes to a pre-release build of BBEdit 10.5.2, which resolved this bug:
 Fixed bug in which the “Search and Replace” Automator action would commit a malfunction when “Use Grep” was turned on in the action’s options.
Perfect! After downloading and installing the latest pre-release build of BBEdit 10.5.2, which Bare Bones makes available on their BBEdit Talk mailing list, I was back in business 20 minutes later. I would certainly have preferred not to spend even 20 minutes hunting down the fix, but bugs happen, and what’s most important is how a developer acknowledges problems and addresses them. Simply put, by being transparent about changes and open with pre-release builds, Bare Bones made me feel that they actually cared about helping me get my work done with BBEdit.
It’s trite to say that the difference here is that Bare Bones is a small company with tens or perhaps hundreds of thousands of users, whereas Apple is a multinational behemoth with millions of users. I have no sympathy for that stance — companies like Apple with $137 billion in cash don’t get to beg off on creating systems and acting in ways that empower their customers. This entire situation could have been avoided if Apple had published complete release notes about Pages 4.3, and recovering from it would have been a lot easier if Apple had acknowledged there could be a legitimate reason to want to downgrade and made instructions and older versions available.
This sort of behavior isn’t new for Apple. But the company’s pretense that even professional users don’t need access to technical details falls flat when things don’t work properly, and more and more, Apple software — from iOS 6 to Pages 4.3 — has been falling down. Great hardware, increasingly sloppy software. Apple never wants to admit problems with its products, which is totally fine at the marketing level, but utterly unacceptable at the support level. That’s why it was so notable that Tim Cook apologized for the iOS 6 Maps problems — that was marketing. But release notes posted on Apple’s support pages? The only people who read release notes are the people who care about changes in the software — these are
support documents, not marketing pieces, and failing to admit bugs or acknowledge foundational changes reveals Apple’s lack of respect both for those of us who rely on Apple products and for the work we do.
I’m not about to make any grand statements about switching away from the Mac or even dropping Pages in the near term — the goal is to get my work done, and that’s best accomplished with the tools I have and know. However, I’m starting to feel like Charlie Brown and the football, with Apple playing the part of Lucy, so when it comes time to look for new software tools, I’ll be looking for companies that won’t keep pulling the ball away from me.