Localization and FrameMaker
Wednesday, June 7th, 2006“Localization and FrameMaker” (pdf): insights and guidance on preparing for localization, choosing vendors, understanding the localization process, and anticipating costs. Details.
“Localization and FrameMaker” (pdf): insights and guidance on preparing for localization, choosing vendors, understanding the localization process, and anticipating costs. Details.
I though I need several minutes to write a FrameMaker script. Script had to change font size in a block of text. What could be simplier? Unfortunately, global apply doesn’t work: text in tables isn’t affected. The only solution I found is to walk over all table cells and re-apply new properties. I dislike the solution, but it at least work.
Superior comment from Stefan Gentz (TRACOM).
Here you go with a list of characters that are *not* possible with FrameMaker (as long as you don’t use any patches) as far as I have isolated them from alphabets of several languages.
It seems that text format rules, which are defined in a FrameMaker EDD, are lost when updating text insets.
I like Kynosarges‘ comment on the Tree Help Plugin for Structured FrameMaker.
This auxiliary entry is reserved for collecting descriptions of the Tree Help Plugin for Structured FrameMaker.
I’ve got feedback from Scott Prentice on recently released Tree Help plugin for FrameMaker. He has added the plugin to his leximation.com tools database. But it’s not important. MIFML — that is important. MIFML is an XML representation of a FrameMaker MIF file. Being the author of TeXML, an XML vocabulary for TeX, I’m sure that MIFML is a very good development.
I’ve released Tree Help plugin for FrameMaker as shareware. I don’t expect much (if any) income, but I have a vague feeling of usefulness of releasing the plugin.
Sometimes I write texts for the Structured FrameMaker, sometimes I solve problems and support solutions for this program. My productivity is increased after I wrote Tree Help plugin.
One of the use cases for XPath over legacy data is structured FrameMaker (FrameMaker+SGML). The structure is in fact XML, that’s good. But the only interface to this XML is something tree-like which is worse than DOM.
Unfortunately, Slovakian letter ť (latin small letter t with caron) is not supported by FrameMaker.
Recently I got a complaint from an user that my FrameScript code did not work. Understanding the problem was a valuable experience.
A year ago I wrote a script for managing reusable components in FrameMaker. It has being expensively used. Saying more, it’s a core of a new workflow.
Recently users reported a bug. Their comments for components where not displaying.
After some exploration, I realized that comments never were used by the code. At the time of writing the script there were no comments and even no agreement on how to make comments, so I implemented a fallback behaviour (using the first paragraph of a component as the comment).
All the year the users were getting the fallback behavior, and it was right!
It’s hard to create menu scripts for FrameMaker, even with help of FrameScript because there are a lot of details. So several months ago I wrote a generator of FrameScript (fslgen). Now I create XML-file with description of desired menu structure, describe handlers and properties, and the generator does all the dirty work.
When the software appeared first, it was a kind of experiment and just a tool to simplify my work. But now the generator is so essential part of the development process, that I can’t understand how I programmed without it.
Right now I’ve finished alpha version of a maker of folios. There are a lot of PDFs possible which differ only in variants. In my solution, the possible variants and the differences are described in FrameMaker itself. fslgen takes the description and produces appropriate menus and scripts. A screenshot (click here for better view):
Quite impressive, isn’t it? And what’s the more important — users can change the menu structure without a programmer!