Monthly Archives: January 2012

Apple iBooks Author and Adobe FrameMaker?

First let me point out that I’m a bit of a Mac-head. After 30+ years of using “IBM PCs” I made the switch to Macs a little over two years ago. Mac desktop (Mini), Mac Server (Mini), Mac laptops (MacBook and MacBook Pro), not to mention the iPhones and iPad. Yeah, completely jumped ship. I do still perform most of my work on Windows, but it’s all in VMs (Virtual Machines) on Apple hardware. It was the best move I’ve ever made .. far more productive, and far fewer problems (both hardware and software). From my perspective, Windows runs best on a Mac.

So, because I’m a late-comer to the Mac world, I wasn’t terribly bothered when FrameMaker dropped the Mac platform (in retrospect, it seems like a bad move, but that’s not the point). Frame works great in my Windows VM .. no problems at all. The fact that it’s not a native Mac application doesn’t really matter to me since I’m usually working in that VM.

I’ve been using FrameMaker for 20+ years, and not only use it for authoring and publishing of content (mostly software and technical manuals), but I also develop plugins and tools for FrameMaker. FrameMaker has its detractors, but in my opinion it’s a very solid authoring and publishing tool for both structured and unstructured content. I like it.

I’ve also been involved with eBook development for the past couple of years, and find that to be an exciting new option for publishing. There is no “perfect” path for creating an eBook from FrameMaker .. lots of options, some better than others depending on your needs, but they all have issues that typically require manual tweaking of the output.

With the release today of Apple’s iBooks Author application (free, but requires the Lion OS), I thought it might be good to explore how this tool potentially fits into the technical document publishing workflow. Also to see if this tool might be a replacement for FrameMaker in certain situations.

In case you missed all of the hype (info and video here), iBooks Author is Apple’s answer to making it easy for authors and publishers to create beautiful and highly interactive eBooks. This syncs up with their effort to provide interactive textbooks for students as eBooks. One caveat is that these eBooks can only be used on the iPad (not even the iPhone, for now), and in fact the license agreement requires that the output from this application can only be used on the iPad and sold through the iTunes bookstore. I won’t get in to whether that’s a good thing or not, but if the iPad is a target device for your content, this may be a useful tool.

If you’re familiar with Apple’s Pages application, you’ll feel quite comfortable with iBooks Author .. it looks like they cloned Pages to make this tool.

First hurdle .. how do you get content from FrameMaker into iBooks Author? IBA appears to only import content from an Apple Pages file or a MS Word DOC file. (No XML import and not even an RTF import.) FrameMaker exports to RTF, which you can open in Word and save to a DOC file. Once you’ve got a DOC, you can then insert that file as a “chapter” or a “section” into the IBA file (iBooks Author files have an IBA extension). When adding the DOC file to the IBA you have the option of preserving your document styles, but regardless of the setting of this option, your style names are all lost (as far as I can tell). All paragraphs are tagged with a style name of “Free Form”. YIKES. As a hard-core style user, that sounds like a really bad thing to do. Hopefully I’m missing some option to maintain style names .. if not, that’s a serious flaw. However, even without any style tweaks, the default appearance does look pretty decent.

Update 29 Jan 2012! Sorry .. looks like I was wrong about that. Selecting the “Preserve styles option” does maintain paragraph and character styles (and style names) on import.

When I tried the import process on some of my content, it seemed to have trouble with conditionalized text. This text looked fine in Word (after the export from Frame), but after importing into IBA, the first character of each conditionalized paragraph was missing. If you make use of conditions in FrameMaker, be sure to watch for this. Also, it appears that cross-references don’t convert into anything useful on the IBA side, and referenced images are lost.

Let’s assume that your content has been successfully imported into an IBA file. You’ll need to create the cover and title pages as well as set up the copyright and other frontmatter. You can import directly into pages of these types, or just insert a copyright section page and copy+paste into that page. An interesting “feature” of eBooks created from IBA is that there is a separate table of contents for each chapter. You’ll need to be sure to tag paragraphs appropriately for them to show up in each TOC.

One of the really interesting things about this tool is its ability to add various types of interactive graphics (called Widgets). These can be simple things like a gallery of images (swipe left and right to see more) and movies or audio files. Or, you can create more complex objects like multiple choice review questions, or interactive images with callouts that pop up when tapped. You can also embed a Keynote presentation, interactive 3D images, and HTML content. All of this must be manually created.

When you want to preview your book, just plug your iPad into your computer, and click the Preview button. Within a minute, you’ll be able to page through and review/test the iBook you’ve created.

If Apple is really hoping that people will create lots of these iBooks, they should work a bit more on getting a cleaner import process. Graphics and cross-references should definitely not get deleted, and maintaining the source style names would be very helpful. Otherwise, there’s quite a bit of manual work to import your existing content and creating a new book. Granted, any of the interactive media will need to be created manually since that didn’t exist in the source.

While a conversion from FrameMaker to iBooks Author is probably not the most common workflow scenario, it may be worth the effort if your goal is to create an interactive book for the iPad. I don’t see this application replacing FrameMaker (or Word for that matter) since it really only allows for a very limited type of page-based formatting, and you can’t export to anything other than iBook, PDF, and text.

I’ll be playing with this more over the coming weeks and will post more as I explore the options.

FrameMaker: EDD, template, rules – what is all that and how does it benefit me?

People often complain that it’s too hard to edit XML files in FrameMaker. Before you can effectively edit files you need to set up a structure application for that XML model. A structure application is a set of special files and instructions that tell FrameMaker how to apply formatting to the XML tags and content in an XML file. This information is stored in a file called the structure application definition file, which contains all of the “definitions” for each structure application available to FrameMaker.

If you’re given an XML file to edit, and are provided with the structure application for that XML model, it’s easy to install the structure application files and start editing. However, if you don’t have a structure application, creating one can require a bit of effort when all you want to do is make some edits. If it’s not important to work in a WYSIWYG mode, you can edit your XML file without setting up a structure application as long as the file includes a valid reference to a DTD. You can toggle the tags on or off and make edits to the content as needed. But if you’ll be doing any significant editing, it’s likely that you’ll want some amount of formatting (even if it’s just to distinguish between block and inline elements and make headings bold). This really isn’t all that different from other XML editors that provide a WYSIWYG or “Author” editing mode. They all require some type of configuration or setup to associate elements and contexts with a particular formatted representation of those elements.

Keep in mind that although FrameMaker is often associated with book production and page layout (which it excels in), the formatting applied by your structure application does not need to use or imply page-oriented formatting. In fact, you can make the formatting look very basic, like a simple web page. Personally, I like to encourage this approach when authoring XML documents. If you’re authoring XML, you are probably producing deliverables for many different output formats, and it’s best if the author is not writing with any of those output formats in mind. When working in this way, you’ll have two structure applications, one for authoring which uses a very simple layout, and one for publishing which applies the page-based formatting that you want in a printed book.

While FrameMaker is actually very similar to other XML editors in features and functionality, it’s important to keep in mind that FrameMaker is not just another XML editor. In addition to being an editor (for both unstructured and structured documents), it is also a state of the art print publishing engine. Most (all?) other XML editors require a completely different tool in order to render the XML tags and content into a format that is acceptable for a printed page or book. With FrameMaker you get both tools in one, and with that added power comes a bit more effort up front. This is a significant advantage, and in the long run, well worth the extra effort.

I like to think of the FrameMaker XML authoring process as “front-loading” the publishing effort. Once you can edit an XML file in FrameMaker, you can also get a beautiful PDF file ready for printing or online delivery. Other XML editors may allow you to edit the XML file quickly, but in order to generate a PDF, you’ll need to learn XSL-FO (or hire someone who knows it), then buy an FO rendering engine to create the PDF. (XSL-FO is an open source language for transforming XML into PDF.) Yes, there are other options for creating a PDF from XML other than XSL-FO, but they all require considerable amount of knowledge and coding and/or a considerable amount of money.

The icing on the cake is that a PDF generated from FrameMaker is likely to look much nicer than one generated from an FO-based process. XSL-FO just does not support the same level of formatting and layout as that available within FrameMaker, no matter how much time you spend on crafting the FO stylesheets.

Granted, there can be a fair amount of effort required to create a structure application from scratch. It’s often best to start by cloning an existing structure application, but if that’s not possible, you’ll just have to make one yourself or hire a consultant to develop one for you.

The core components of a structure application are:

  • DTD (Document Type Definition). A set of markup declarations that define the elements and their relationship in an XML or SGML data model. The DTD also defines any attributes and their default values.
  • EDD (Element Definition Document). Similar in concept to a DTD, but adds a layer of context rules to allow the mapping of formatting properties to the data model based on the relationship of elements and attribute values. An EDD can be created from a DTD, but the context rules must be added to assign formatting to the document when it is opened. The context rules can assign formatting properties directly, or it can assign paragraph and character styles that are defined in the template.
  • Template. A FrameMaker file that defines the page layout properties, named paragraph and character styles, and other document-specific settings. The EDD is imported into the template file, making the template a single file that contains both the structure rules and formatting information.
  • Read/write rules. A file that defines additional properties of specific elements and how those elements are modified as the XML file is read from or written to disk.
  • XSLT import or export stylesheet. You can optionally include XSLT stylesheets that perform additional processing on the import or export of an XML file.

References to all of these files (and other settings) are included in a structure application definition in the structure application definition file. For details and to learn all that you’ll need, refer to the Structure Application Developer’s Guide (http://www.adobe.com/support/documentation/en/framemaker/).

The nice thing is that once you have the structure application, even if you didn’t create it yourself, you’re likely to be able to make adjustments to the template to affect the layout or formatting of specific elements without assistance from a consultant. This is because you’re just changing properties of a standard FrameMaker template, something that you or someone in your company has probably been doing for years with unstructured FM files. If you’re using an FO-based process, unless you have the necessary expertise in-house, you may need to hire someone to make these modifications. You’ll hear people say that once the template is “set”, you don’t need to worry about further customizations, but that doesn’t mesh with the reality of the publishing process I’ve seen. People are always making little changes.

Another nice thing about using FrameMaker as your PDF publishing tool is the ability to leverage the “generated list” feature for creation of the Table of Contents, Index, and other front or back matter lists. As with the structure application template, setting up a nice looking Table of Contents or Index is just a matter of setting up a generated list template as done with unstructured FrameMaker. No special programming knowledge required, and it’s easy to test and modify as needed.

Publishing from FrameMaker can be done “by hand” on the desktop, by creating a book file from the XML content, then applying the necessary pagination and numbering properties and adding the generated list files. Or you can set up a publishing process that’s partially or completely automated. Because FrameMaker has extensive API support (FDK, ExtendScript, and FrameScript), there are many automation options. This does require purchasing automation add-on components or coding-up your own tools, but much of this can be achieved with minimal expense and/or training.

Both Adobe Technical Communication Suite (TCS) and FrameMaker Server provide a tight integration between FrameMaker and RoboHelp, so in addition to the PDF publishing offered by FrameMaker, you can publish to various types of online Help. This can provide an alternative to using XSL as the method for converting XML into HTML-based output.

When setting up an XML publishing workflow, people are often drawn to XSL and XSL-FO as the means to transform their XML content into online and print deliverables. In some cases one or both of these are in fact the right choice. But if it’s possible that the output formatting will require frequent modifications or if the level of formatting is not sufficient for your needs, FrameMaker is likely to be the best solution.

Because FrameMaker is a standards-compliant XML editor, it can be used in an authoring environment along side other XML editors. FrameMaker can also publish XML content that was authored in other XML editors. The great thing about XML is that it frees your content from being tied to a proprietary authoring or publishing tool. That doesn’t mean you won’t still need to use proprietary tools, you just have the flexibility to mix and match those tools as needed. Your task is to choose the right tools to match your needs. Keep in mind that FrameMaker is not just another XML editor, it might just be the best XML editor for your needs!

— Scott Prentice, President of Leximation, Inc.
Developer of DITA-FMx and FMx-Auto, tools that provide extended DITA authoring and publishing features in FrameMaker.


This article was also posted to the Adobe Technical Communication Blog.