FrameMaker and FrameMaker + SGML are state-of-the-art tools which offer a plethora of options for the creation of a unique publishing style and look. A single user would have few or no problems in maintaining a consistent style provided that he or she has a clear conception of the desired final appearance. Any styling changes in mid-stream would nevertheless cause some amount of grief as the new changes would have to be applied to pages previously completed. The level of severity would depend on the frequency of such alterations and the volume of the work in question.

In a larger production environment in which a team of authors are required to adhere to specific style guidelines, the problem is amplified by an order of magnitude. Wherever documentation is produced and updated constantly the quality and consistency of deliverables can easily deteriorate unless strict directives are put into effect and observed by production personnel. Typically, a committee of publishing professionals would exist for the specification of a unique style which the company will adopt. Precise specifications of the style are then handed down to a service group, or a contractor like Pendulum Software, where designers will apply the style to authoring templates and software engineers will create the necessary programs for processing the authored data for delivery. The software tools will be developed on the basis of the specific properties defined in the templates.

It is therefore imperative that writers not have the capability of changing any of the formatting properties as designed within the templates. Furthermore, if the authoring environment implements structured documentation such as with FrameMaker + SGML, it is even more critical that the structuring rules defined in the templates not be altered by writers.

FrameMaker does provide for the removal of functions from the product's interface. In order to protect against author tampering one would remove all reformatting functions such as the paragraph, character and table designer functions, and the EDD definition and import functions. A FrameMaker workstation environment having full editing powers and limited, or no design capability can be created. There remains one problem: changes in design will always arise.

A professional production system is not complete without the power of implementing changes broadly and efficiently. Imagine the dilemma of having to manually re-import template properties into thousands of documents. When multiple production templates are in use the problem is amplified exponentially. A FrameMaker document carries all formatting and structural object design properties within itself in a header section which, at Pendulum, we like to call the "catalog". A thousand documents created with the same template must all carry an identical catalog. Surprisingly, FrameMaker does not provide a feature for the automatic updating of the catalog across documents. Another downfall of this architecture is that it is wasteful of storage space with varying degrees of impact dependent on the ratio of catalog to document body within the data files. We hereby present a solution which would guarantee that FrameMaker files will always incorporate the latest template version in their catalog section.

We propose the creation of an API Client program which would modify or replace the "File->Open" function in a FrameMaker workstation installation and which would also be incorporated into the template designer's platform in addition to the product's original "File->Open" function. This function would automatically perform a "catalog refresh" algorithm by which the current template is unconditionally re-imported over the existing catalog. This operation is perfectly safe if there are no format overrides within the document body protion of the file. If files are always created and edited in a FrameMaker workstation environment devoid of design powers, the absence of format overrides can be guaranteed. Whether current templates reside on a central server or are delivered to workstations with every update is not an issue.

The proposed API Client would also require an identifier from within a document file bearing the name and location of the pertaining template which is to be imported. The simplest solution would be to code a template identifier inside a master page variable.

If you are interested in more details on this proposition please contact us at Pendulum Software or send a message from our Contacts page. We cordially welcome your ideas and comments.

© 2004 - Pendulum Software Ltd.