I have created a great workflow for developing Acrobat forms, using FrameMaker, FrameScript, and TimeSavers from MicroType (http://www.microtype.com). Using this workflow makes it practical to use FrameMaker to develop PDF forms. FrameMaker’s graphic and table features can be used to layout great looking forms, while TimeSavers eliminates nearly all of the required Acrobat post-processing. A set of FrameScript scripts streamlines the insertion of the TimeSavers markers in the FrameMaker documents.

If you have a need for Acrobat forms, or are interested in the process, please let me know. I will be glad to provide a demonstration of the process. Also, I am soliciting a few more forms to do for free that I can use for demonstration purposes. If you have a forms that you would like converted to Acrobat forms, please let me know. In the meantime, take a look at some of the forms I have developed using FrameMaker, FrameScript, and TimeSavers:

http://www.rickquatro.com/forms/ClientQuestionnaire.pdf
http://www.rickquatro.com/forms/LosersAreWinners_Men2.pdf
http://www.rickquatro.com/forms/LosersAreWinners_Women2.pdf

-Rick

I have a client using MIF2Go to generate DITA from unstructured FrameMaker documents. They are very happy with the entire process with one exception: They want an easy way to rename the href values in the DITA map, and the corresponding topics on disk. I have proposed a set of FrameScript scripts that will automate the process. The script proposes new topic names, based on the topicref’s navtitle value. You can have the script automatically use the new names, or you can use a “semi-automatic mode” where the old names and proposed new names are written to and Excel file. Then you can use Excel to fine-tune the new names. A second script quickly applies the spreadsheet names to the DITA map and corresponding topic files.

You can take a look at the documentation here. The cost for the set of scripts is $95 US. To purchase the scripts, please contact rick@frameexpert.com.

–Rick

Maxwell Hoffman recently posted “Top 10 mistakes FM Uses make in content before translation” on his blog (www.tinyurl.com/gpi-fm1). One of the mistakes is having markers within words instead of at the beginning of words. I decided that this could be solved quickly and easily with a FrameScript script. You can download the free script at
http://frameautomation.com/MoveMarkers.zip. It will process all of the markers in the active document or book, allowing you to solve the problem in seconds. Instructions are in the included ReadMe.text file. If you need to purchase FrameScript licenses, please contact me for discount prices. Please let me know if you have any questions or comments.

–Rick

There are many useful FrameMaker plugins out there, but one of my favorites is FrameSLT by West Street Consulting, operated by Russ Ward. I was reminded of how powerful it is when I recently helped a client add structure to a large number of unstructured documents. One issue was a very specific sequence of elements where text nodes needed to be wrapped in <cmdname> elements. In the screenshot below, I have the text nodes indicated by red rectangles. The yellow highlighting indicates the specific context where the text nodes needed to be located.

Doing it by hand would entail searching for <codeph> elements and then visually checking their parent elements to see if the text nodes should be wrapped. This would not be a reasonable approach for hundreds of documents to process. Enter FrameSLT, which allows you to use XPath expressions to search for element/attribute combinations in structured FrameMaker documents. Here is a screenshot of FrameSLT’s “Node Wizard” with the XPath statement in place.

Here is the breakdown of the XPath statement:

//text()

Start at the top of the structure and find unwrapped text nodes.

[parent::codeph]

Make sure the text node is a child of a <codeph> element.

[parent::codeblock]

Make sure the <codeph> element is a child of a <codeblock> element.

[parent::section[@outputclass="cli-syntax"]

Make sure the <codeblock> element is a child of a <section> element, whose outputclass attribute value is “cli-syntax”.

As you can see, XPath lets you be very specific with the elements and attributes that you are trying to locate.

If you look at the lower highlighting on the Node Wizard screenshot above, you can see that FrameSLT lets you perform actions on the elements that it finds. In this case, we want to wrap the text nodes in <cmdname> elements. FrameSLT can perform this operation on hundreds of text nodes in seconds; the results are shown in yellow below.

FrameSLT has a bunch of other useful features that we won’t go into here. Try out the demo version and you will discover more powerful tools for working with structured FrameMaker documents.

One more thing to mention for FrameScript users: FrameSLT can be controlled by FrameScript scripts and FDK clients. This gives you the capability to use XPath in your scripts (and plugins), which greatly simplifies the code required for locating elements and attributes. For more information, visit West Street Consulting.

– Rick

I have developed a FrameScript solution for one of the “bottlenecks” submitted to me a couple of weeks ago. A common problem is imported graphics reported as missing when files and folders are moved or renamed. The FrameMaker user actually wanted the ability to rename screenshots and quickly update the references to them without reimporting them. But this solution would normally be used to quickly “repoint” images to new folder paths.

The result is a set of FrameScript scripts called ManageImagePaths. Here is how the solution works:

• You run a “Collect Image Data” command that prompts you for the documents you want to process. You can collect image data from a single document, book, or all of the documents in a folder (and optional subfolders). The result is a single .csv file containing all of the imported image data.

• You open the .csv file in Excel, where the image data is listed in columns. The columns include the document name, the page where the image is located and the folder and file names of the images. Columns can be rearranged and rows can be sorted so you can easily find and edit the appropriate data. You can update folder and file names in any of the rows.
• After the data is edited, you run the “Update Image Paths” command, which will prompt you for the edited Excel spreadsheet. The script quickly updates all of the image paths in the appropriate FrameMaker documents. Only images that you changed are updated. The script can update hundreds of FrameMaker documents in seconds.

The cost for the complete solution is $95, including the FrameScript source code and documentation. To purchase the scripts, please contact rick@frameexpert.com.

Here is a FrameMaker tip that doesn’t require any plugins or scripts. When you are working in a FrameMaker dialog box with Include/Don’t Include list boxes, you can quickly move all of the items from one list to another by holding down the Shift key and pressing the left or right arrow key (highlighted in yellow in the screenshot). To quickly move a single item in the list, you can double-click on it.

File this one under the “learn something new every day” category. This question was posted on one of the Framers lists today:

Our documents have the potential of being generic to be used in multiple manuals. To achieve that, our safety icons are in a common location. The FM files and associated graphics should always be together. When we move the folders to another manual, everything should remain relative. With FM8, writers go to our server and open a file, if the graphics are not positioned correctly, the writer updates the location and FM8 changes the location to absolute. Subsequent files that are opened and saved change the graphic path to absolute and do not ask for the path change. Is there any way to shut this off so that if a file is opened and the relative path is incorrect, that it asks for the path update? The only other way of verifying the path is to do a LOR.

I spoke to the author of the post to make sure that both his FrameMaker file and image were on the same drive; he assured me that they were, so I couldn’t see any reason why the link shouldn’t be relative instead of absolute.

So I set up this test to try to duplicate his problem. I created a FrameMaker file here

E:\Test1\Test2\Test3\DeleteMe.fm

with a link to this graphic

E:\Graphics\GPL_Tick.eps

I closed the FrameMaker file and copied it to various locations on the E drive. To my surprise, no matter where I copied the FrameMaker file, it still pointed to the absolute path of the image. I had expected it try to maintain a relative path, for example

..\..\..\Graphics\GPL_Tick.eps

Apparently, if FrameMaker has to reach to the root of the drive to build or update its link to the image, it automatically creates an absolute path instead of a relative path. The way to ensure a relative path is to make sure that there is at least one common folder below the root. For example, if I use these paths

E:\Docs\Test1\Test2\Test3\DeleteMe.fm

E:\Docs\Graphics\GPL_Tick.eps

then I get the relative path (..\..\..\Graphics\GPL_Tick.eps) that I expect.

–Rick

FrameMaker automation is not all about FrameScript and plugins. Sometimes a tip or shortcut can increase productivity, and even small increases add up over time. If you have a FrameMaker tip or trick that you would like to share, please let me know. If I publish one of yours I will give you a free Carmen Publishing Inc. plugin of your choice.

I have seen a couple of problems with the FrameMaker Word 2007 import filter in FrameMaker. It seems that some Word formats do not import correctly like they did with Word 2003. The “by hand” solution is to open the Word 2007 (.docx) files and save them out as Word 2003 (.doc), and then import the Word 2003 files into FrameMaker. This was not an attractive solution for one of my clients that was using FrameScript to import the Word files into FrameMaker.

Since FrameScript can control Word via its EActiveXObject object, the solution was to modify the script so that it performs the Word 2007 to Word 2003 save down automatically. Here is basically how it works:

1. The script looks for the file extension when it is passed a Word file. If the extension is .doc, it proceeds as usual.

2. If the file extension is .docx, the script passes the file to a new function in the script. The function opens the .docx file invisibly with Word, and saves it out to a temporary Word 2003 (.doc) file.

3. The script continues with the import with the newly created Word 2003 file. After the temporary file is imported, it is deleted from the disk.

The nice thing for the client is that her original automated process is restored, and she is able to work with both Word 2007 and Word 2003 documents.

–Rick

Last week, I posted a request on the Framers and FrameScript mailing lists, requesting your “favorite” FrameMaker bottlenecks. By bottlenecks, I mean the tedious, error-prone FrameMaker tasks that you have to perform. Or, it could mean a missing feature that you wish FrameMaker had.

I received a hand full of thoughtful responses, but one request I think would be the most useful would be a way to manage FrameMaker images. Here is an excerpt from the email I received:

My bottleneck is graphics — naming graphics consistently, and then finding and updating graphics in a document/book and getting rid of old graphics no longer used. For example, for a current application to which I am writing, I am having to document a Wizard that does function “X”. I am now on my third iteration of this wizard and all of the pages in the wizard have changed again. I need to recapture 10 screenshots and replace them in my current document. I know that I can save the new captures with the same name as the old captures and in the same location because I import by reference but, that’s not really handy for me because the previous captures are named RunWizard_Page1, RunWizard_Page2, etc. and >>NOW<< the Wizard is going to be named the Project Wizard and so I would like to take new captures name them ProjectWizard_Page1, etc. and somehow get these to replace my old captures rather than having to reimport, save them with the new name and/or delete the old named captures. Am I asking for the moon?

It occurred to me that this task might be best handled outside of FrameMaker and in an Excel spreadsheet. Here are the advantages I see:

1. You can quickly extract and manage a large amount of image data by going from FrameMaker to Excel via FrameScript.

2. You can use Excel’s tools to quickly analyze the image data by sorting, rearranging columns, etc.

3. You can use Excel’s find/replace function to quickly change the image data you want. The image file and path could be listed in separate columns in the spreadsheet, making it easier (and safer) to do find/replace on just folders or file names.

4. You can extract image data from multiple books and combine them into a single spreadsheet and update hundreds of common images at once.

This would basically be done with two FrameScript scripts: the first would extract the data into a .CSV file, which can be opened in Excel. The second script would update the image paths in the FrameMaker documents from the content of the Excel file. Both scripts would run in seconds, even with large amounts of image data.

What do you think? If this solution appeals to you, or you have any suggestions for making it better, I would love to hear from you.

–Rick