Category Archives: XML

Using Coderefs in DITA-FMx

One of the possibly more under-appreciated features of DITA 1.2 is the <coderef> element. A <coderef> lets you include the content of a non-DITA code file within a <codeblock> element. Using a <coderef> can help to ensure the accuracy of your documentation by including real working code samples.

DITA-FMx 2.0 provides complete support for the <coderef> element. (Default FM-DITA does not support this feature.) This video provides a quick (2.5 minute) tour of authoring and publishing. For publishing, it demonstrates the use of the CodeFormatter plugin for providing syntax-based formatting of code samples in DITA-FMx.

» Link to video on YouTube.

FrameMaker 11 Review: XML and Structured Authoring

Despite the fact that FrameMaker was one of the first authoring tools to support structured authoring (FrameBuilder and SGML in 1991 then FrameMaker and XML in 2002), it is still seen by many as purely a book authoring and publishing tool. While it excels at long document production and provides excellent page layout and formatting capabilities, it also offers a robust XML authoring interface and related features. However, in the XML community, it’s generally not taken seriously as an XML editor. The release of FrameMaker 11 may start to change this perspective.

One of first things that people may say when asked about FrameMaker and XML editing is, “you can’t see the angle brackets, so it’s not an XML editor!” Well, with FrameMaker 11, you now have a real Code view authoring option. This isn’t just a simple text editor, it’s a real XML code editor with many of the productivity features you’d expect in a professional XML editor.

FrameMaker 11 is packed with lots of features, for both structured and unstructured authoring. In this review, I’ll just be focusing on the structured authoring and XML features. I was involved in the FrameMaker 11 prerelease testing, and have had the opportunity to offer suggestions and report bugs during the development cycle. I’m quite pleased with the way this release has turned out, although I am one of those people who always wishes that the “bake time” was just a bit longer.

Performance is always on the list of new features. Adobe claims that DITA maps and topics open faster in FM11. To be honest, with my working files I’m not seeing a significant change from FM10, although we’re talking about an open time of a few seconds, even for large maps, so I wouldn’t expect much improvement there. In tests of extreme cases of element use, I do start to see some significant improvement with FM11. I’m seeing a decrease in file open times of up to 92%; that’s a pretty significant change. One document (100 pages with very dense use of inline elements) took over 7 minutes to open in FM10, and only 36 seconds in FM11. Wow. While this test may not represent real-life content, it does show that some serious work was done to speed things up.

Smart Paste is a new feature that lets you copy and paste from HTML or other rich text sources like Word, and automatically have the styles converted into your structured model. FM11 comes pre-configured to support Smart Paste into DITA, but you can customize this feature to work with any data model. This will be a huge time savings when migrating existing content. The resulting element structure may not be exactly what you want, but it’s much better than the old way of copy and paste. I think that this will be a very popular feature.

Banner Text is a new feature that provides a clickable label text in newly inserted elements to help guide the author as to the type of content to place in an element. Values such as “title text” or “list item” are defined in the EDD, and you can change them to suit your needs. When combined with the ability to set up boilerplate (or “straw man”) content through the use of the element auto-insertion feature in the EDD, you can make it much easier to start writing a new topic, and will make it easier for people to get more comfortable with structured authoring. The default DITA templates are set up this way.

Authoring of structured documents (and XML files) has been made even easier through some new keyboard shortcuts. Pressing CTRL+1 displays a popup list of all valid elements at the current insertion point. Not only can you easily select an element to insert, but this list also lets you select multiple levels (as deep as the model supports) of child elements so that with one click you can insert many levels of nested elements. CTRL+2 does the same thing but lets you wrap the current selection with the selected structure. CTRL+3 provides a change option.  CTRL+7 gives you quick access to setting an attribute value. I love the ability to insert multiple elements with one click!

Another great new keyboard shortcut displays an inline attribute editor. Use Esc,i,a,e to pop up a small window that allows selection and entry of attribute values at the current insertion point. Yes, that’s a bit of a long “shortcut,” but you’ll get used to it!

Now you can easily author XML files without creating a structure application. One common complaint about using FrameMaker as an XML editor was the belief that you had to create a structure application in order to edit an XML file. Although this wasn’t strictly true, it wasn’t entirely obvious how to work with XML files without a structure application. Now one of the New File options is “Empty XML,” which is just that, an XML file that isn’t linked to a DTD or structure application. You can quickly create an XML file of any arbitrary model, or one that’s linked to a DTD for validation, but no structure application is required. You can also open up and edit any XML file, as you’d expect from an XML editor.

Whitespace handling has been greatly improved. Because the Code view mode includes a pretty printing option, the system is designed to handle pretty printed content without trouble. In the past it was often problematic when you were working in a mixed editor environment, and some people pretty printed their content. This should no longer be a problem!

FrameMaker adds two new authoring views in addition to the standard WYSIWYG view. You can now work in “Author mode,” a stripped down WYSIWYG view, which lets you focus on the content rather than thinking about the formatting or page layout. You can also work in “Code view,” which provides access to the underlying XML coding if you prefer to see the “real” XML under the hood.

Code View!

Providing a Code view option in FrameMaker is huge. It’s definitely not something that all FrameMaker users will use, but there are times that you really do need to modify the underlying XML coding, and this provides you with that option. There are people who are more comfortable editing code directly, and this lets them do that right inside of FrameMaker. No need to use another XML editor just because you want access to the XML coding. What’s nice is that FrameMaker remains in the authoring mode you last used. So if you’re in Code view, and you quit for the day, when you come back the next day and open an XML document, it’ll start off in Code view.

Code view has all of the productivity enhancements that you’d expect in an XML editor. Standard features like line numbering, syntax coloring, and code folding, make it very easy to work with large documents. Also, as you type, you are presented with auto-suggest popups for element and attribute names as well as automatically adding the closing element tag. Because of the runtime XML validation, any invalid coding is indicated with a squiggly underline as well as being reported in the Errors panel, if that is enabled (View > Pods > Errors).

Code view also offers an XML Tree view pod. This is a simplified version of the standard Structure view pod available in the WYSIWYG view, but is really just used for easy viewing and selection of element groups. Unfortunately, you can’t use this view to move elements, maybe in an update?

Code view also provides an XPath parser to allow flexible searching in the current file, all files in a map, or all files in a folder. This will greatly simplify the process of locating that content that you know is somewhere on the file system. Once authors get comfortable with basic XPath syntax, this will be very popular. It would be great to see this method for searching for files available in the other authoring views, not just in Code view. One caveat, which will hopefully be fixed in an update, if you perform an XPath search on a folder, you’ll get errors for files in that folder that are not parsable, such as FM binary files. Not a big deal, just a little annoying, since you’d expect it to just skip those files silently.

In addition to XPath support, Code view also provides the ability to run an XSLT transformation on the current file, all open files, or all files in a folder. You can create XSL scripts that perform various operations, and just pop over to Code view to run the script as needed. Granted, not all FrameMaker users will be writing their own XSLT scripts, but once they start to see the power behind it, more people will give it a try.

Yes, there are a couple of problems in Code view:

Preformatted content can run into trouble when passed through the Code view. If you’re working with a data model that includes elements like a <codeblock> or <pre>, the content in those elements should not be indented via the pretty printing process. Unfortunately, in FM11 it currently is, which will likely cause formatting problems in your output. I’m hoping that this is something that will be addressed in an early update, but until it is you may want to avoid opening files in Code view that contain preformatted elements.

Another problem with Code view is one that affects older systems that have a single single processor core (or virtual machines with only one core assigned). If you’re one of these groups you can pretty much forget about using Code view in any useful manner. Apparently the XML validation requires two processor cores, so systems with one, will notice a serious lag time between keypresses. This can be mitigated by selecting “No Application” for the structured application name, but that’s not really a good solution in the long run. While this should only affect a small number of people, it’s pretty serious if you’re one of those people. I’m personally hoping that this is at the top of the “fix” list.

DITA Support

As with the previous release, FrameMaker 11 continues to support the DITA 1.2 specification (as well as DITA 1.1). A number of fixes have been made that make it easier to work with FrameMaker in a mixed editor environment and issues have been resolved that created potentially non-compliant DITA topics.

URI notation (for href, conref, etc. attributes) now properly uses the forward slash as the directory delimiter instead of the backslash. A setting in the Options dialog controls this feature. Make sure that “URI Notation for Paths” is selected, and your files will be compliant in this regard.

Cross-reference format names are now stored in the xref/@outputclass attribute rather than the @type attribute, making this feature compliant with the DITA specification. When opening topic files created in earlier releases of FM, your format names will be migrated to the proper attribute. However, note that migrated topics will contain both attributes going forward unless you do something to strip out the @type values. It seems like you’d want the invalid values removed from the @type attribute (so it could be set to the value of the target topic type), but perhaps this will make for an easier transition from earlier versions of FM since it will continue to work properly in both environments. If you are migrating to FM11 and not planning to go back to editing topics in earlier versions of FM, you should set up a script of some kind to strip out the old @type values. (This might be a good use of the new XSLT transformation feature!)

By default, maps open in the Resource Manager, which makes for a very nice map editor. While this is a very useful and efficient view for most map editing operations, such as inserting and arranging topics, it does not yet allow for editing of relationship tables. You’ll need to switch to Document view for that (same as in FM10). Also, the new cool keyboard shortcuts for working with elements and attributes (described earlier) don’t seem to work in the Resource Manager. When you do switch your map to Document View, you’ll see an odd looking structure with your topicref titles shown twice, once for the clickable label and once for the navtitle element. Would be nice to get this cleaned up at some point.

Unfortunately, frontmatter and backmatter elements are not supported in FM11. When you try to insert a <toc> or <indexlist> element in a bookmap, you’ll be required to specify a target file. Because these elements represent generated lists, there’s typically no reason to specify a target file. Add this to the list of things I hope are fixed, sooner rather than later.

DITA map publishing has been greatly enhanced. Now when you save a DITA map to a book with components, the resulting files will have the pagination and numbering applied and any generated files will be included (TOC, Index, etc.). These properties are defined in the ditafm-output.ini file (found in %appdata%\Adobe\FrameMaker\11). This INI file also lets you specify that the “chapters” are aggregated FM files rather than multiple FM files as nested topics (GenerateFlatBook=1), as well as other options for controlling the output. The enabling of generated lists is done through this INI file as well, which is a bit odd, since the DITA bookmap structure provides a perfectly nice model for this purpose. In fact, if your bookmap does specify frontmatter and backmatter, this will be ignored, and only the lists defined in the INI file are used.

I think that the enhanced map publishing is a big step in the right direction, but it falls short of being as useful as it could be. For one, there’s only one INI file. This assumes that all of your books use the exact same properties and generated lists, which is likely not the case. Also, it’s a shame that the generated lists aren’t enabled by the existence of the associated frontmatter or backmatter elements in the map being processed. Finally, it would be really nice if this INI file was to some degree exposed through a user interface, frequently editing an INI file is a bit cumbersome.

Summary

In my opinion, FrameMaker can now be considered a full featured XML editor. That combined with its ability to perform impeccable page layout functions, makes it the ideal authoring and publishing tool for all types of documents and workflows. If I could have only one editor, FrameMaker would certainly be that tool. If you’re an existing FrameMaker user, you should definitely download the trial or give this new release a test drive. If you’re in the market for an XML editor, don’t rule out FrameMaker before you try it; compare the features and benefits of FrameMaker with other XML editors, and you may see that it’s quite the worthy competitor.

 

PDFs from DITA with FMx-Auto, oXygen, and Ant

If you’re not satisfied with your current DITA to PDF workflow, you might consider FMx-Auto. FMx-Auto enables automated (scripted) publishing of a DITA map through FrameMaker and DITA-FMx. This can be integrated into most publishing workflows on the desktop or server. If you’re interested in getting high-quality PDFs from your DITA content, like you used to get from unstructured FrameMaker, this may be the solution you’re looking for.

As an example of using FMx-Auto for publishing to PDF from a popular XML editor I set up an Ant script that creates the necessary AutoFM script from the current DITA map file name, then passes that to FrameMaker. The AutoFM script instructs FrameMaker to use the DITA-FMx Map-to-Book process to create a book and chapter files from the DITA map. This book is then saved to PDF.

This Ant script can be modified to suit your needs and can be used by other tools and publishing workflows as an integration option for publishing to PDF from DITA through FrameMaker. FMx-Auto supports FrameMaker versions 7.2 through 10, so even if you’re not using Frame for authoring, you can still use it for publishing.


Best viewed at high resolution

Resources and information:

Automated DITA to PDF Publishing with FMx-Auto

If you’re publishing PDFs from DITA and want high quality with minimal effort, you should consider using DITA-FMx and FMx-Auto. If you’re already using FrameMaker and DITA-FMx, FMx-Auto will enable you to create the same PDFs you’re getting through manually saving the FMx-generated book to a PDF, using scripting or batch processing.

If you’re currently generating PDFs through an XSL-FO based process, and aren’t satisfied with the quality of those PDFs, FMx-Auto will enable you to take advantage of FrameMaker’s layout and formatting capabilities, while still using another XML editor for authoring. These tools support all versions of FrameMaker from FM7.2 on up through 10.

DITA-FMx and FMx-Auto can be installed with FrameMaker Server to provide a PDF publishing solution linked to your CMS or other server-based publishing process.

Just because you’re using DITA doesn’t mean that you have to give up high-quality PDFs!

  • DITA-FMx provides features to control the formatting and layout of a PDF generated from a DITA map. These features are easier to use than similar options you might find in other PDF creation tools.
  • FMx-Auto unlocks the API in DITA-FMx so you can automate the book and PDF creation process. An FMx-Auto installation includes the AutoFM plugin as one way to drive this automation.
  • AutoFM is an XML-based scripting tool for automating processes within FrameMaker. In this case it is used to open a DITA map and run the DITA-FMx Map to Book process to create a fully formatted FrameMaker book, then save that book to a PDF.

See how easy it is to get well formatted PDF output from a DITA map using FMx-Auto and DITA-FMx. This video provides a quick (5 minute) overview of the entire PDF publishing process using FMx-Auto.

» Link to video on YouTube.

Information and download:

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.