📄 On FROFF: A Text Processing System for English Texts and Figures

Summary

The paper presents FROFF ("Flexible Run OFF"), a document formatter from Osaka University. It produces camera-ready English papers that contain figures, tables, line drawings and mathematics, and it runs on modest laboratory hardware. Its predecessor was the authors' typewriter-based ROFF, which used fixed-width characters. FROFF instead drives a cheap dot-printer, which makes it a low-cost alternative to TROFF, since TROFF needed an expensive phototypesetter under UNIX.

The system is written mostly in FLISP, with output drivers in Fortran and Assembler. It offers:

• proportional character widths;
• fonts and sizes that can be switched mid-text;
• relative positioning in any direction;
• picture output from disk or a TV camera;
• a user-extensible rule (macro) layer on top of about 60 primitive commands.

Processing happens in stages. First, rules are expanded. Next, each command is evaluated by calling a corresponding LISP function. Finally, the result is converted to printer data.

The authors typeset this very paper with FROFF. They report it is practical overall, but note three weaknesses: math is handled awkwardly, the system is slow, and terminals often lack lowercase input. To work around the last two, they draft in ROFF and convert the text automatically.

Key points

• Hardware: an HP2108A minicomputer (64 Kbytes) with a 256 Kbyte auxiliary memory. This memory is split between the FLISP free list and an image region. Output goes to a Versatec dot-printer.
• Fonts and units:
  • About 60 commands are available.
  • Fourteen fonts exist, and 60 are planned.
  • Each glyph has its own width; for example, "I" is 13×12 dots and "W" is 29×32 dots.
  • Lengths can be given in MM or CM, and 1 cm equals 78.8177 dots.
• Rules: rules are declared by name from a library, or defined by users with the ".." construct. A rule's body may call other declared rules. The .St and .Rs commands push and pop system parameters, so a rule's side effects (such as a font change) can be undone afterwards.
• Automatic capitalisation: words after a sentence-final period are capitalised, while words after "i.e." or "e.g." stay lowercase. This lets text be typed on uppercase-only terminals. The drawback is that deliberately all-caps strings need special rules.
• Math limitation: expressions are split into blank-delimited "units", the same as ordinary text, so formulas can break apart. The authors concede that TROFF is better here.

Interesting ideas

• I1. Users write high-level named rules that are first expanded into a small set of primitive commands, and only then is each primitive executed by its own function, which keeps the core small and lets the vocabulary grow without touching the engine.
• I2. Rules explicitly save the parameters they change and restore them on exit, so local formatting effects never leak into surrounding text.
• I3. Capitalisation is decided by simple common-sense rules (capital after a period, lowercase after "i.e."/"e.g."), and the paper openly names the case these rules get wrong.
• I4. A fast, cheap fixed-width system is used for drafting and debugging, and a translator converts its input for the slower high-quality system while passing math and figure commands through unchanged.
• I5. The authors validated the system by producing their own conference paper with it, which exposed real usability gaps such as speed and math handling.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (back): Generation templates could be macro-like rules that expand into a fixed set of primitive realization operations, so new constructions are added as rules while each primitive step stays individually traceable.
• I2 (world): Hypothetical, negated or reported contexts could push a scoped copy of world state and pop it afterwards, keeping counterfactual facts from contaminating the main world of the text.
• I3 (tokens): Sentence splitting and truecasing could use a small explicit rule set with an abbreviation exception list, documenting the known failure cases as test items.
• I4 (tree): UD dialect converters could likewise rewrite only the relations that actually differ and pass everything else through verbatim, with the quick perceptron parser for iteration and gparse for final output.
• I5 (learn): Running Mova end-to-end on its own documentation or course material as a standing dogfood test would reveal practical weaknesses that isolated benchmarks miss.