RoboHelp mobile output uses the International Digital Publishing Forum (www.idpf.org) ePub standard. This means the output can run on any device that supports ePub, like the Barnes & Noble Nook, Android devices with ePub readers, Kindles (with some extra work that doesn’t involve RoboHelp – see http://kindleworld.blogspot.com/2009/08/ million-free-google-books-in-epub-for.html) and others.
RoboHelp creates mobile output using a script that you import into RoboHelp itself. (This is similar to how Adobe added AIR support to RoboHelp – using a plug-in in v.7 before adding it to the interface in v.8. If the mobile market takes off, I’d expect to see Adobe follow the same path and build the script into the interface in v.9.)
What follows is an overview of what’s involved mechanically and design-wise in converting a fairly standard project to mobile format. The project is a proof-of-concept I created for a Boston-based maritime historical to which I belonged from 1990 to 2003. Members of the group built museum-class ship models, and my idea was to create an online “book” about the models and have it sold in the museum store as a fund raiser for the group.
Here’s the main screen and default topic:
And here’s a fairly typical topic screen.
The project had a TOC, index, header and footer in one topic, breadcrumb trail, table and graphics, internal links, an external link, popups, and an audio file. My question was how well the project would convert to mobile with no effort on my part.
The first step is to download the ePub generator script and a file archiver, both free. (See Ankur Jain’s blog at http://blogs.adobe.com/techcomm for instructions.) A few caveats – you’ll have to change the name of the script file to ePubGenerator.jsx and modify the script – a minor step into code – to specify where you put the file archiver on your PC. You can then import the script into RoboHelp using the Script Explorer. Finally, you have to change the XML handler using RoboHelp’s XML support feature.
You can then open the project to be converted to mobile format and run the script. After you specify the output folder, RoboHelp will create the ePub output. Here’s the result in Adobe’s ePub viewer – Digital Editions. First the main screen and default topic:
And the topic.
The result? Mechanically, pretty good. Without making any changes to the initial project, here’s what I got…
• Text converted correctly, as expected since ePub offers “reflow” of text. The text also resized correctly when I used the resizing options on the viewer.
• The TOC came across fine.
• Internal jump links worked fine. External jumps worked too, but opened the target pages in a new browser window. This is okay if your users will read the book in a full browser, like Firefox with the ePub reader add-on, but not if users will read it in a “true” reader. Popups did not work, which I assume is because ePub doesn’t support them.
• Graphics seemed to come across fine.
The problems I found seemed to have more to do with apparent incompatibilities between help project features and the ePub standard, and design.
• The index didn’t convert. I’m not sure if this is because ePub doesn’t offer one or because of something that simply hasn’t made it into the conversion script yet.
• The search tab didn’t convert. It was replaced by the ePub viewer’s search tool, as can be seen, with some difficulty in the images above, at the end of the toolbar.
• One oddity – the project apparently converted to one text file when viewed in the Digital Editions viewer but individual topics when viewed in Firefox. I assume there’s a reason for this that I simply haven’t found yet.
• Projects meant to be single sourced to ePub, in addition to any other outputs, need greater and more rigorous use of CSS. Basically, avoid local formatting – good advice under any circumstances.
• Adobe recommends setting sizes as % rather than the usual points. You’ll have to do this for everything, not just text. Also, don’t use hard returns for paragraph or table row separators because these double when rendered in ePub. (Compare the paragraph spacing in the pre- and post-conversion versions of the default topic, and the spacing of the table rows in the pre-and post-conversion versions of the ship topic.) Instead, specify the spacing as part of the style for the items in question.
• There are also some formatting requirements described in Ankur’s April 23 post.
Finally, as you’d expect when converting content from big-screen to little screens, you’ll have to decide what content is “need to know” versus “nice to know,” such as graphics, and be prepared to conditionalize out the latter. You can fit many graphics in the mobile output by making their sizes relative, with the % unit of size, but a graphic may become small enough to be illegible. Think of this as single sourcing taken to an extreme level.
The biggest benefit of this support for mobile output is the fact that it makes it easy to try mobile without buying and learning new software. And, if you don’t like the result or it’s not what you needed, just delete the output, delete the script (or just ignore it), and go back to your regular output.
And, again, it’s challenging and fun to figure out how to output to mobile…
No comments:
Post a Comment