Structured In-Doc Table of Contents for standalone FM Book components

I’ve heard queries from several FrameMaker users regarding the requirement of having TOCs for documents that are part of a book. The need arises when users want to generate standalone output of individual chapters of a book. Basically the idea being the document is individually capable of having an output along with its own TOC and that it should not have any bearing or impact on the TOC of the entire book.

You can achieve what you intend to do much more efficiently by creating a standalone TOC of each individual chapter component and then importing it as text inset in the beginning of the document. That way every time you modify your document you would just need to update your standalone TOC and then update the text inset. Your links from output for individual chapter would remain intact.

I’ve tried preparing a book with chapters having an in-doc TOC as a sample. Download.
This might reduce effort as compared to the other way I’ve heard users achieve the same outcome, i.e. by creating cross references in the document to create the TOC effect.

Will be glad to know if anyone finds it useful.

FrameMaker and the XML Whitespaces Normalization

Amongst the blitz of all the features packed in Adobe Framemaker 10 release one feature missed the limelight. And that’s XML whitespace normalization. The problem used to arise when XMLs pretty printed in other XML tools were brought to Framemaker. FrameMaker would not ignore whitespaces introduced by other XML editors, resulting in excess spaces in paragraphs and table cells and unnecessary spaces between paragraphs. Various solutions in the form of XSL transforms were commonly being used in the techcomm community.

Although it was debatable whether what Framemaker was doing was the right thing or not? We thought that it is concern faced by many FrameMaker users and hence decided to resolve this issue. Now with Framemaker 10, your XMLs pretty printed in other tools would open perfectly fine. This should provide XML authors relief from handling such spaces by manual deletion or by use of an XSLT . FrameMaker would drop and ignore such spaces appearing in the element contents in the following scenarios:

  1. Multiple Spaces occuring in the middle of the element content.
  2. Whitespaces occurring at the element endings.
  3. Whitespaces around inline elements (with/without sibling inline elements).
      NOTE: If you are a heavy user of inline conrefs in DITA parlance you might want to switch this normalization off as described below. Else you might find spaces between inline conrefs getting collapsed.
  4. XML provides a special attribute ‘xml:space’ for controlling the whitespace handling at the element level. This attribute shall be honored if specified. @xml:space has only two valid values as per the XML specification – ‘preserve’ and ‘default’. Therefore for
    1. default: Whitespace handling mechanism shall be used as per the FrameMaker’s setting.
    2. preserve: Whitespaces shall be preserved as per the old behavior; ignoring any of whitespace related settings in FrameMaker.

If at any point in time you want to revert back to the earlier behavior you have the flexibility to modify the maker.ini preference setting “RemoveExtraWhiteSpacesOnXMLImport” to enable/disable this feature. By default, this is enabled.

Please share any feedback that you might have.

CMS connectors configuration for Framemaker

We have received a number of queries regarding the configuration of cms connectors(especially for EMC Documentum CMS). Users trying to connect to any CMS can refer to this helpful Adobe techcomm blog post for all the details.
For Documentum it is necessary to have custom types installed on the Documentum CMS so that the document dependancies can be handled by FrameMaker, say for example between a book and its child components. Two configuration methods have been posted-one is the through the DAR installer and the other approach is using an executable shipped along with FrameMaker. The executable way is reported to have not worked for some of the customers. In such a scenario you should be using the DAR installation route using Documentum Composer.

Automatically link an application to any XML file in FrameMaker

Do you know we can associate an application directly with an XML file?
This will save our time through the lengthy process of first opening a structured application file, reading the definitions and selecting the application from the list while XML file opens and closes. Besides, we face other difficulties when we require dealing with multiple application files. Suppose we are closing an XML file; we need to make sure that the application with which the XML file is being saved is indeed the app from the correct structapps file. Saving with incorrect application may sometime be catastrophic. This will lead user to redundantly keep performing the task of reading structapps file as I discussed.

To link a structured application with an XML file, all we need to do is to write in a PI (processing instruction) statement in the XML file. This PI will contain the path of structapps file and name of the app within it. The statement can be written in one of the following three forms:

<?Fmwd AppLocation "structapps_path" AppName "application"?>

<?Fmwd AppLocation "structapps_path"?>

<?Fmwd AppName "application"?>

If AppLocation is provided, FrameMaker will silently read file from structapps_path while we open and save the XML file else Frame will use previous read structapps file. If AppName is specified, the application will automatically be associated with the XML. If AppName is not there, the file at structapps_path will still be read; the only difference will be that the user will be prompted to choose from the list of applications by himself. If application is invalid i.e. not present in list of applications, the XML file will be opened with No Application.

Note that the PI has to appear before the root element of the XML file. Here I am showing an example XML code with a PI instruction:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="simple_table.css" type="text/css"?>
<?Fmwd AppLocation "" AppName "simple_table"?>

<?Fm TrackChange Off PreviewState PREVIEW_OFF_TRACK_CHANGE?>

<myBook Author = "Klark"
xsi:noNamespaceSchemaLocation = "simple_table.xsd"
xmlns:xsi = "">

Since DITA files are also XML based, Frame will process this PI in DITA files too. The structapps_path can be either an absolute path or a relative path as shown in code above. Relative paths will be relativized with respect to the XML file location. Further, structapps_path can also point to a file at HTTP location.