How Take Control Makes EPUBs in Pages
A long, long time ago (to be precise, in 2003), Adam and Tonya Engst conceived the Take Control series. It was to be an “ebook-first” series, meaning that the manuscripts were written and formatted right from the start with the idea that they would be read as ebooks. It was possible to print them, of course, but they were really designed for reading onscreen. In those early days, the authors of Take Control books prepared their manuscripts in Microsoft Word X on the Mac.
Word was an obvious choice: Tonya, who created the first template, was an agile user of Word’s advanced features, and she knew that there was an Adobe Acrobat Pro plug-in for Word for Windows 2003 that would enable her to export PDFs that included clickable Web URLs, internal links, and bookmarks — that is, so long as the authors created the manuscripts to spec. Back then, PDF was the only widely used ebook standard, and for an “ebook-first” series, hot links and bookmarks were (and still are) required.
(Regrettably, the Mac versions of Word are, to this day, unable to generate a PDF with links and bookmarks. And, yes, there is more than a little irony that the Mac-focused Take Control series was exported to PDF with Windows software — until earlier this year when we switched away from authoring in Word. That said, Tonya did use Word on the Mac to export a PDF that she then swapped in to replace the visible layer of the somewhat ugly Windows-generated PDF, thus gaining the links and bookmarks from the Windows version and the better-looking PDF from the Mac version.)
Also, Word had long been a de facto standard in the book publishing world, which meant that all Take Control authors owned it and knew how to use it. Word offered a plethora and a half of formatting features, which meant that our authors could, with a little guidance, produce manuscripts that were close in appearance to the final PDF file that we distributed. That is, they could write directly into their layout, thus eliminating extra production time that would otherwise be needed to flow their final words into the final layout. Word’s advanced table-formatting features were especially useful, and tables were used to create grids for eye-catching visual elements such as figures and highlighted tips.
The Way it Was — In those early days of the series, PDF was (as it remains) the primary format for published Take Control books. Within a few years, though, we started offering print-on-demand versions (generated from the PDFs, run through Apago’s PDF Enhancer to shrink them to an appropriate physical trim size), and in late 2009 we even started publishing most of our titles in two other ebook formats, EPUB and Mobipocket. But, for the vast majority of our readers, PDF continued to be the format of choice.
This was far from surprising: the print-on-demand books cost significantly more than the PDF versions and took longer for customers to obtain than the downloadable PDF versions. As for the two non-PDF ebook formats we offered, the market was tiny, since few people had, or used, ebook readers.
As a result, we focused the bulk of our energies on producing our PDFs in-house and delegated the production of the other versions of our ebooks to our reselling partner O’Reilly Media. Given the low demand for these other versions, a short delay between the publication of the PDF version of an ebook and its availability in other formats seemed acceptable.
Then the Kindle with its Mobipocket format appeared, breathing life into the languishing ebook market, and, after the Kindle, the iPad. The iPad was immediately important to many people who read Take Control ebooks. And, although there are several excellent options for reading PDFs on the iPad, ebooks in EPUB format, such as those sold through Apple’s iBookstore, have become a fundamental part of the iPad experience.
But we were still using Microsoft Word to prepare our manuscripts, and our relationship with Word was a difficult one. Although it gave us our dealbreaker feature — the capability to add links and bookmarks to a long manuscript — and it supported many other desirable features, it also was, well, flaky. And, we were often under so much time pressure to finish ebooks quickly that we could not take the time to track down and share with Microsoft the exact nature of each and every problem we encountered. Without going into all the sordid details, let’s just say that 100-plus-page Word documents with huge amounts of change-tracking and comments do not always behave well. In addition, the internal links our books required were fragile
and painstaking to create and correct, resulting in a lot of effort going into checking and fixing links.
Meanwhile, as interest in the iPad and mobile ebook reading took off, we realized that outsourcing our EPUB book production, with its associated time lag, was not working well for many of our readers. Also, outsourcing meant that we had to relinquish control over the final look and feel of our EPUBs. But, for the longest time, we weren’t able to find a viable alternative to Word that would let us generate our PDFs, work in a feature-rich writing and editing environment with our formatting showing as we wrote, and generate EPUBs too.
Enter Pages — A few months after releasing the iPad, Apple released a minor update to its iWork productivity software suite for the Mac, which included an update to the Pages word processor. Included in that update was the capability to export Pages documents to the EPUB format (see “iWork 9.0.4 Gives Pages EPUB Support,” 27 August 2010). Taking the revised Pages for a spin around the block, Adam discovered that it could import a Word manuscript for a Take Control book and export both a decent PDF and a credible EPUB version of it. Metaphorical bells rang and
imaginary light bulbs turned on.
Tonya took on the side project of converting the complex welter of Word paragraph and character styles used in Take Control manuscripts to Pages equivalents. The object of the exercise was two-fold: to see if Pages could produce the look and feel of a Take Control book in PDF form from a Pages manuscript, and to see if, with minimal effort, that same manuscript could produce a satisfactory EPUB version, with the definition of “satisfactory” being something at least as good in appearance and navigability as those that were already being made available to customers.
Most Take Control books use about 12 custom character styles, and nearly 60 custom paragraph styles, so there were a lot of styles to consider. Plus, many of the table-based layouts had to be abandoned, since Page’s table features are blunt tools when compared with Word’s many refinements and because tables make less sense in the EPUB format (more on that in a moment). Furthermore, while Pages and Word are similar in many ways, their internal content models have some subtle (and some blatant) differences. Adding to the complexity were the limitations of the EPUB content model itself as compared to what is possible in a PDF.
Dealing with the limitations of the EPUB content model is no small undertaking. By comparison, the PDF content model is a powerful and complex thing, designed, among other considerations, to produce onscreen as close to an exact copy of a document’s printed appearance as possible. In a sense, PDFs live at the intersection of print and pixel: an onscreen PDF (such as a Take Control book) should look exactly like a printed version of the document, with the same fonts, colors, and layout characteristics, including the same pagination.
The EPUB format, on the other hand, was designed to present documents in a readable way on portable digital devices, allowing the EPUB reading software to adjust the layout and appearance of an onscreen document to conform to the characteristics of the device on which it is read. Identical presentation of the fonts, layout, and pagination of an EPUB from one device to another is not what the format is about. The device, and the user of the device, are in control of much of the appearance of an EPUB book. While an EPUB book can look rather like a printed version of the same book if enough care and trouble are taken in its design, it will never look exactly like it, and there is no guarantee that any two readers will see the book in
exactly the same way, unlike with PDF.
Reflecting the limitations of the EPUB format, the EPUB documents exported from Pages can use only a subset of the formatting capabilities of Pages itself: in its EPUB exports, Pages ignores, among other things, bordered text boxes, floating text and graphic elements, and various other features.
So Tonya not only had to convert the Take Control styles from Word to Pages, she also had to create versions of those styles that would look attractive both in a PDF and when reduced to those visual characteristics that an EPUB reader — such as the iBooks app on an iPad — can reproduce. With a lot of trial-and-error experimentation and rethinking of the purpose of each of the styles, Tonya eventually came up with a set of styles required for producing a PDF ebook and an EPUB ebook from the same Pages file. This project took about 40 hours of work spread out over a number of weeks. (Note, however, that Tonya’s original set of styles continues to evolve as we develop more understanding of how Pages produces EPUBs.)
In addition to rethinking the ebooks’ visual appearance, Tonya and Adam had to figure out what to do about what they considered key ebook features — the hot internal link, the hot Web link, and the bookmarks list. Creating a hot internal or Web link in Word was a slightly unreliable and fussy business involving the Hyperlink dialog, which Microsoft has never updated in any significant way through various versions of Word. Some authors eventually developed automation to help them through it and Tonya ended up linking up a lot of ebooks by hand, using a Keyboard Maestro macro for some of the heavy lifting. At least the Adobe Acrobat PDF plug-in for Word for Windows did generate bookmarks
Luckily, Pages includes a feature for making internal links and Web URLs, which we’ve found to be extremely reliable. However, nobody on the Take Control team has found a satisfactory way to automate it, so the process in the Link Inspector is more manual than we would prefer. At least, however, once we set a link, it sticks around reliably.
We ran into two problems with PDFs exported from Pages. First, for each bit of text that’s a link, Pages creates two PDF links, one stacked on top of the other. The functional effect for the reader is the same — clicking either link works. The problem, however, is what the reader sees while clicking — PDF links can either show a box around the clicked link or can invert the screen around the link. With either, the fact that the clicked link likely doesn’t cover the link text entirely is disconcerting. Luckily, it turns out to be easy to select all links in Acrobat Pro and change their highlight style to none — there’s no visual indication at all that a link has been clicked now. It’s the lesser of the weevils, and
hopefully Apple will fix this unfortunate bug in the next revision of Pages.
Second, PDFs exported from Pages lack bookmarks associated with the headings in the document. This caused us consternation, since we’d rather not add them by hand during the final moments of production. Adam’s first solution involved using Smile’s PDFpen Pro, which provides tools for making bookmarks quickly from selected text, but that was still more involved than the technique he eventually settled on: using Aerialist X Pro, an Acrobat plug-in from Debenu that offers several advanced PDF manipulation features, including one that builds a hierarchical set of bookmarks automatically based on scanning for text in
specific fonts and sizes. (Another tool that’s worth a look for this task, if you’re on a budget, is PDFOutliner.)
Making the Switch — Having a set of styles for producing an EPUB does not a workflow make. For starters, we needed a set of style guidelines and instructions for our authors, as well as a template document containing all of the necessary styles, so that they could start working in Pages.
Coming up with those instructions and that template was only part of the task, of course: the other part was helping the Take Control authors to switch from one working tool, Word — software with which most had become comfortable and productive over the years — to a completely different one. Several authors, however, had been encouraging us to switch away from Word for years, even if they couldn’t suggest a viable alternative, and Joe Kissell, in particular, was supportive of leaving Word, which was important given the number of books he has written. (Now that Nisus Writer Pro provides EPUB export and many other welcome features, Joe is looking at whether it could take over from Pages.)
An even bigger task was figuring out how to convert our collection of existing manuscripts from Word to Pages. After all, many Take Control books are updates or new editions of existing Take Control books. Simply importing those Word manuscripts into Pages is not enough: the original Word styles, designed for producing PDF output from Word, have to be replaced by Pages styles designed to work both for EPUBs and PDFs.
In addition, in the move to Pages, Tonya took the opportunity to rationalize the set of Word styles that had grown organically over time into a set of Pages styles that were more consistently named and organized in the Styles drawer in Pages. This means that most of the styles in a Word version of a Take Control manuscript have to be replaced by hand with differently named Pages equivalents.
The style conversion process has all sorts of hidden pitfalls: for example, the numbered and bulleted list styles that we used in our Word manuscripts avoided Word’s auto-numbering and auto-bulleting capabilities because we did not like them — they were overly helpful, and too often guessed wrong about what styling we wanted to apply. The equivalent Pages styles, however, have been a big help in speeding up production and keeping our numbering correct. But using auto-generated bullets and numbers means that converting a Word manuscript to Pages involves a lot of search and replace work, removing all of the manually inserted numbers and bullets that the Word manuscript contains, as well as setting and checking the automatic numbering
and bullets produced by the Pages equivalents.
There are many other finicky differences between the Word styles and the Pages styles that require massaging. Tonya had to develop a written set of procedures for performing this conversion so that she wouldn’t have to memorize all the steps, nor be the only person who knew how to do it.
This procedural document currently consists of 30 major steps, along with substeps and notes. The original document had even more steps and involved running the Word document through the HTML format and a tremendously complex BBEdit text factory to clean up the internal links sufficiently so they could work in Pages. Over time, however, Tonya decided to dump Word’s links (which have several oddities that make them harder to work with in Pages) in favor of re-creating them in Pages, giving the documents a fresh start, link-wise. Not including any necessary re-linking, for a typical manuscript conversion from Word to Pages, running through those steps and double-checking the results takes about 2 hours — not an inconsiderable amount
of time, but not a huge amount either, especially when compared to the amount of time required to write and edit a book!
Making a Book — Actually producing both PDF and EPUB ebooks from a Pages manuscript is, however, a far less arduous undertaking than converting a Word document into its Pages equivalent.
Currently, there are roughly 15 steps that need to be performed on a final edited manuscript that are the same for both the PDF version and the EPUB version. None of these steps are particularly difficult, though some are time-consuming (for example, one of those steps is to check every single link in the manuscript, both internal links and links to external sites, a process that can take an hour or two for a link-heavy manuscript, but which, thankfully, seems to be required only once — if a link works in either the EPUB or the PDF, it will work in the other version of the ebook).
Once those steps are performed, the document branches: one branch becomes the PDF and the other becomes the EPUB. By developing a workflow that branches only near the very end of the production process, we can be reasonably sure that both versions of a book contain identical content: usually, all typos and other minor errors in the content are addressed before the branching occurs. If a typo is discovered in either branch after the split, we do have to fix it in both branches, but that’s minor.
For the EPUB branch, there are about ten steps that we follow to make the manuscript ready for exporting. One of those steps involves replacing three styles, out of the several dozen in the manuscript, with modified styles that work better in EPUB. To be specific, the Pages EPUB exporter cannot produce multiple adjacent block paragraphs that share a colored background, such as the ones we use in chapter openers and sidebars. Therefore, we substitute paragraph styles that use first-line indents instead of empty space following the paragraph for those color-background paragraphs. We also adjust the ebook’s page margin settings (EPUBs don’t need page margins; the EPUB reader supplies its own), remove the Table of Contents (the Pages
exporter creates its own EPUB table of contents), provide a cover page designed for the EPUB version, and export the EPUB.
After that, it’s a matter of visually checking the book in an EPUB reader for any obvious visual anomalies. For that, we look the book over in iBooks on an iPad in both horizontal and vertical orientation, using the default iBooks font, Palatino. We also may do spot-checks of the book in Firefox, using the EPUBReader add-on (see “EPUBReader Displays EPUBs in Firefox,” 10 September 2010). The entire process following the branch usually takes less than an hour, with the bulk of the time devoted to the final visual check.
Once all that’s done (and a similar number of post-branch steps performed for the PDF version), the ebooks are ready to be loaded into our Take Control catalog and made available for sale, something that takes Adam a few hours as he deals with the different content management systems involved at that final stage.
What’s Next — Developing and refining our in-house workflows and document styles is a continuing journey. Books, especially technical books like Take Control books, are inherently complicated, and there are often exceptions or adjustments to our template that we have to make to accommodate a particular book’s content — after all, the template is the servant of the content, not the other way around.
What’s more, we have yet to find a good way of producing Mobipocket (Kindle) format ebooks in-house: the KindleGen software that Amazon makes available for making Kindle books is something of a black box, and we have yet to find a way of employing it in-house that produces acceptable results with heavily formatted books, so we still outsource the production of Mobipocket ebooks to O’Reilly. But maybe someday a good EPUB-to-Mobipocket converter will appear (Calibre isn’t it, before you ask), and if it does, we’ll be able to bring the Mobipocket production in-house as well. It’s also possible things will change when the recently announced Kindle Format 8 becomes available, along with KindleGen 2.
We are finding certain frustrations with Pages that we didn’t anticipate. A big one is comment retention: In Word, a comment sticks around even if the text that it is associated with is deleted. So, in Word, an editor can highlight a word, insert a comment, and write “I think you made a typo in this word.” The author can easily perceive the problem, delete the word, and re-type it. However, in Pages, the author’s act of deleting the misspelled word also deletes the comment, so neither the editor nor the author can refer to it if a question remains about the edit. We’ve had to be much more careful about comment placement, and more wordy because the comment can’t highlight the text that it is discussing.
Another frustration is with navigating a manuscript in Pages: Word’s optional Navigation pane, which neatly shows the table of contents in a sidebar at the left of the main document display area, is sorely missed by some Take Control people. Tonya has resorted to opening a second copy of the Pages document and viewing its table of contents or using Outline view to simulate this functionality — she finds the ability to see the big picture while editing in a small area to be extremely important, especially when she considers the paths that different readers might take as they click through the internal links in the final ebook.
Nonetheless, the adoption of Pages, with all of the work we had to do to get there, is beginning to pay off for us: we are able to produce new Take Control books and revise existing books more quickly and efficiently than ever, and with more attractive results for the EPUBs. Not bad for a few dozen hours of hard thinking and research, and with a word processor that costs less than $20!
Greetings Michael - I have the same problem with MS Word's inability to produce good PDF output. I decided to go the InDesign CS5 route, but then discovered that InDesign's pdf output (although linked, tagged, and bookmarked) does not produce accessible results. The Adobe Acrobat Accessibility checker indicates hundreds of issues, and fixing them one-at-a-time is like chipping away at a large rock using only a knife and fork!
My question: Does Apple's Pages produce good quality pdf output that also passes the Accessibility tests. Acrobat Pro (v9.4.6) has accessibility profiles for §508, W3C Guidelines 1 and 2.
When I run the Accessibility Checker on our books from Pages (and processed by PDF Enhancer), it complains about graphics without alternate text, and "inaccessible links" that are not contained within the structure tree. I think, though I haven't looked that closely, that the inaccessible links are the secondary link that Pages makes for every PDF link. So it's not terrible.
With our previous technique, images lacked alternate text, none of the contents of any page were contained within the structure tree, and tab order was largely inconsistent with structure order. So if anything, I think we're doing better now.
InDesign CS5.5 added great improvements to creating accessible PDF files. Here's a link to an Adobe TV video (the first of two) on how you can make accessible documents in CS5.5: http://tv.adobe.com/watch/accessibility-adobe/part-1-new-accessibility-features-in-indesign-cs55/
You know, I would be interested in a Take Control book that explained this process in some detail.
Such a book might gain consciousness and replicate itself.
I want it for my perfect Borgian library :-)
We've certainly thought about that in the past, but what may not quite be clear from the article is that everything in our system is tailored for what we're creating - we could teach you to make an ebook that is essentially like a Take Control book, but I'm not sure we could teach you to make an ebook of a radically different design.
Have you considered using the DocBook XML template? I've been tempted to try it for some small projects of my own, but haven't yet addressed the tools issues for editing content and transforming to output formats. Still, something like it seems to be the wave of the future.
Funny you should suggest that. One of my last jobs was with a large multinational software company that used DocBook for its manuals. It required writers to compose their docs using a clumsy and inflexible XML editor, a team of programmers to develop and maintain the XSL transform system to convert the XML to PDF and other formats, did not support much in the way of comment and revision tracking, and, generally, was a very expensive and hard-to-maintain solution.
It was appropriate for a large company that needed to maintain docs in a standardized format in a content-management system for translation and content re-use, but wholly unsuited to the creation of ebooks by freelance writers. As you point out, the tools issue is what makes it impractical for us.
there are better free editors for Doc book (eg Serna)
But my response to this article is amazement.
Amazement that such critical feature for tech docs are STILL not working in Word.
After years of struggling with this myself (and flakey templates that loved to suddenly drop stuff out of the contents, etc...) I tried LyX which drives LaTeX to get a PDF.
It is such a joy to just add links and bookmarks and have it all work.
And get an autopopulated properties....
I am not sure there is ePub output availanble - but it would not surprise me if there was. There are already HTML converters.
Did you look at it and reject it? Too old school maybe ;-)
Too "old school"? Not really; too practical. Publishers need authors. Requiring freelance authors to abandon the tools they use for every other publisher in favor of a specialized one just for us is, I'm afraid, a real non-starter. We'd rather have great writers and a less-than-perfect toolchain than a great toolchain that we can't get great writers to adopt.
Plus, we have to get books out the door today. We don't have the time or the resources to develop a specialized in-house XML/XSL solution and still get books written, edited, and released while developing the solution.
Interesting. I never got the impression from a publisher I could use whatever toolchain I want. Maney forced me to use Word. Then they set it in two columns so all the program listings were unreadable. Now I just ignore the templates and do it two columns with the same margins and it looks how I want :-)
Update: Of course you've tried Scrivener, you wrote a book about it! But I guess since you don't use Scrivener then you don't recommend it for ebooks. Pity too as it looks so good.
Oh well, back to the drawing board in my hunt for a tool to do this ebook thing.
Have you tried Scrivener?
I've written one book using Pages and it has been a maddening experience. I used the template Apple provides for ePub and it seems to work fine for plain text. For pictures it's another matter. I'm in the process of looking at Scrivener which has outputs for ePub, mobi and PDF. It sounds like the solution. Have you tried this and if so what is your opinion?
BTW, it's nice to know I'm not the only one having this problem. All in all I spend more time doing this than I do writing and I'm not happy about that.
I love Scrivener, and think it's a fine product for writing novels and similar long-form texts, and it can produce very attractive PDFs and EPUBs from such manuscripts. However, it is not particularly well suited for manipulating the complex layouts required by a Take Control book.
I'm not sure what kind of problems with using pictures in Pages documents you're having. Take Control books often contain dozens of pictures, and we haven't encountered any serious difficulties placing and manipulating them in Pages.
The book looks fine in Pages and the images are inline, I learned that quickly. :) I export it as an ePub and it looks pretty good using the Nook reader on my Mac. I load the same file in iBooks and the captions are not under some of the pictures, sometimes ending up on another page. If I take that same ePub file and convert it to mobi using an online tool at (http://ebook.online-convert.com/) it looks pretty good on the Kindle app.
The maddening fact is the same file looks different on three different platforms. I think the only way to really control it is pdf but that has it's limitations too.
I wonder if during my machinations with the file that some rouge formatting code got left in and I'm about to try saving it as plain text and starting all over.
I wrote it in three weeks and so far I'm six weeks and counting trying to make it look okay.
Thanks for your comments,
The thing to keep in mind about ebooks (EPUB and MOBI) is that, just as with Web pages, formatting and layout are suggestions only: the limitations of the specific reading device/software used to read the book, along with any user-specified display settings, trump the publisher's desires. Also note that Pages' EPUB output is really tuned to look best in iBooks, not in Nook or Stanza or any other EPUB readers out there.
For accurate adherence to your layout requirements, either PDF or a fixed-layout EPUB (not something that Pages does) is necessary. Liz Castro talks about the fixed-layout EPUB format here: http://www.pigsgourdsandwikis.com/2011/02/fixed-layout-epubs-for-ipad-and-iphone.html
I'm going to strip all the formatting out of the file and start over. I'll let you know how that works out. But if Pages is tuned to iBooks it's doing a crappy job. In my previous comment I noted that iBooks displayed the Pages output the worst of all three.
Thanks for the Liz Castro link. I'll look into that too.
BTW I've been around since the dawn of time and this eBook reader thing is very reminiscent of the early days of web browsers.
The old saying comes to mind that goes something like this, "Standards are a wonderful thing, especially since there are so many to choose from."
Just to finish this off.
Saving the file as text only and then reloading it in with the template from Apple was tedious but seemed to work. There are some oddities. I found that an extra CR before and after each picture caption was necessary to make it look right in the ePub. It's not really WYSIWYG as you have to pretend the page breaks on the screen aren't there. Maybe there's a way to turn that off. It would be much better if it was linear and didn't show them.
Other than odd errors after the export to ePub such as saying it left out footnotes (which I didn't have) etc.
Just 5 hours to do a 57K word file wasn't as bad as I thought it would be. Now I know what to do next time.
Pages is a low cost way to do ebooks but it's far from perfect. BTW I tried the export to Word files and that didn't work when I then tried to convert that to ePub via the above mentioned web site.
It would have been a lot easier without the pictures.
Thanks for the help.
I think the only issue with images in Pages when outputting to EPUB is that they need to be inline, not floating.
Yes, I did that. Read my replies to Michael E. Cohen.
Thanks for replying. I enjoy watching you on TWiT.
As a scientist I usually ask for the best and most professional tool in order to get my work done. So every time I hear that professional writers are either forced to use MS Word or actually chose MS Word ("well, is there anything else I could use?") I'm a bit bewildered. How can a professional WRITER end up using such a horrible tool to WRITE?
Ever since I learned to use LaTeX as an undergrad I've been a big fan. And fortunately in my community, although MS Word has seen some adoption, LaTeX is still considered a de-facto standard that's accepted pretty much by everyone. The day an editor forces me to use Word rather than a professional tool is the day I either switch journals or start wasting time on editing with a inadequate tool. Time I'd otherwise use to pursue research, that is, get actual work done.
As a professional writer, I use whatever tool works best for a given project, taking into account the material to be written and the very real requirements of co-writers, editors, and production staff. Like most professional writers, I want to get paid for my work, and if that payment is contingent upon using a particular writing tool, I use that tool.
In a long and rather varied writing career, I have produced work using (among other tools) Word, Pages, MacWrite, XMetaL, BBEdit, Scrivener, Quark XPress, Wordstar, the UCSD Pascal text editor, HyperCard, and WYLBUR on an IBM 3033 mainframe. Were I the kind of writer who could guarantee sales of the same order of magnitude as a King or a Rowling, doubtless I could stipulate my favorite writing environment, and doubtless the publisher would not only accept it but also offer me a free daily massage in the bargain. But I'm not, and they don't, so I use the tools necessary to get the job done and to get paid.
I too have searched for a way of automating hyperlinks in Pages. It seems extraordinary that Apple have not exposed this functionality in Applescript. The best I could do was this ...
[Much earlier code loading up the target URL into the clipboard] ...
tell application "Pages" to activate
tell application "System Events"
tell process "Pages"
click checkbox "Enable as a hyperlink" of tab group 1 of group 1 of window "Link"
select text field 1 of group 1 of tab group 1 of group 1 of window "Link"
--keystroke "a" using command down
--keystroke "v" using command down
The lines commented out aim to paste the clipboard, but this just doesn't seem to work. Pages apparently forgets the link as soon as the dialog box closes. I resorted to manually pasting in the URL. But at least the dialog box is open and waiting.
I'm really excited about Amazon ditching Mobi for HTML5 and CSS3. Wish they'd come out and say when though. Of course, we'd still be stuck with 2 formats but at least one is no longer Mobi.
Yeah, I'm really curious what will happen with the older devices, which I can't see supporting Kindle Format 8.
I hope the "8" in Kindle Format 8 isn't a subtle reference to 8-track cartridges, because, well... ☺
I was particularly struck by the statement "Tonya did ..., thus gaining the links and bookmarks from the Windows version and the better-looking PDF from the Mac version."
I've done the Windows-Acrobat-to-preserve-links act for years and have continually been amazed that Adobe doesn't generate better looking output from Acrobat. I'd love to know how Tonya does this swap for the improved appearance.
Just print to PDF from the Mac version, and then, in Acrobat Pro, use the Replace Pages command to replace all the pages. The trick is that links live on a different "layer" from the visual parts of the PDF, so if you replace pages, the links remain. You do have to make sure you have the same fonts on Windows such that the link boxes are all in the right places.
It took about a year of producing the Take Control series before I realized that you could not only swap in the occasional revised page that you created by printing to PDF from Macintosh Word, but that you could actually swap in the entire document! This is a tricky process because sometimes the page breaks do not come out the same in Mac Word and Win Word, even if your fonts are the same, but it's a good bet that if the final page count is the same between the two systems, your page breaks are the same (or close enough). If the page count isn't identical, you have to find out why and solve it. Usually I'd make the page breaks work out in Windows so that they'd match the Mac version without regard to content (so I might just delete a line of text), because the Mac version's content would replace all the Windows content.
I hope that made sense! It was a picky, error-prone, frustrating process, but one that gave us much better looking ebooks, so I stuck with it because the end result was worth it. Here in Pages, I don't do that any longer, and it does make my workdays more fun.