Our first three major products for FrameMaker are described below. We can see how far FrameMaker has come these past few years (or past 350 years, human equivalent).
The PEK (Programmable Export Kit) was added to provide even more output flexibility to FM2A. Specifically, PEK converted "flat" FrameMaker output to more structured output, such as that required by other formatting systems such as Nroff/Troff, Scribe, LaTeX, and early HTML. For example, a FrameMaker bullet list merely consists of bullet tags, whereas structured systems require an open and close command for a list environment. PEK could synthesize these structure elements.
PEK was a chameleon, and simply by switching configuration files could be reprogrammed to output basic commands for most structured systems.
A few die-hard users still use FM2A-PEK, but the product is no longer supported nor are any new versions planned.
But this was clunky. A would-be table-making person wrote an ascii file using a mark-up language that looked like Latex. (The syntax was accessible in a configuration file. TableGen let you generate files using Latex, Scribe, or even TBL syntax.) Now, of course, things like tables are done with slick GUI-based editors.
But wait a moment! What goes around comes around. With a few modifications to the syntax configuration file, TableGen could generate FrameMaker tables from today's HTML. We find this humorously ironic, to say the least.
Anyway, TableGen inhaled the ASCII table definition file and shot out a MIF file with a bunch of Aframes and text columns glued together using weird leading and spacing values. These in turn made up an appropriately sized and massaged table based on the TABLE 4 template, with all the content you'd specified. You'd open the MIF file generated by TableGen then copy and paste the table(s) into the main document. Whew.
As awkward as this process seems today, at one time this was about the only reasonable way to create FrameMaker tables with multi-line cells.
HyperGen plowed through all the files in a book. With larger document sets, this could take a while. Couple this with the "steam powered" work stations of the day and a 1000 page book could take the better part of an afternoon and evening to be fully linked. (This was while running on a Sun 350; Sparc 1s cut that time down to an hour or so. Today's systems could do this in a few seconds.)
One of the key design aspects of most FSA tools is providing the user a way to modify product operation. This was true with TableGen's definable syntax; the tradition was carried over to HyperGen in the form of pre- and post-processing hooks. Users could then add in their own processing scripts. One of our clients, for example, wrote an awk script that integrated navigation buttons onto the master pages when HyperGen ran. The buttons were "fresh"; no conditional text had to be jiggled.
We'll be updating this page in the years to come. Wonder what we'll say about today's leading edge tools then?