broff - proposed new troff
budd at arizona.UUCP
budd at arizona.UUCP
Thu Jun 30 02:00:14 AEST 1983
Having waited in vain several years for somebody else to do
this task, I've started to think maybe I should do it myself.
The task is a total rewrite of n/troff. Tentatively, I've titled
the project broff (as in "there are too many cooks in this broff
already"). There are two major reasons for undertaking a project
this onerous (other than escaping from all the even more onerous
tasks i should be doing). The first is that troff is a
notoriously obscure program which is extremely difficult to
understand or to make local modifications to. A rewrite would,
hopefully, be clean, structured, and easy to understand. The
second reasons is that there are several "bugs", "features" or
whatever in troff that have bothered me for years, and some of
this I would hope to clean up.
Like the recent ditroff system, broff would be mostly device
independent, producing some sort of intermediate output which
would then be processed by a postprocessor. The goal is to
produce a system which is compatible with existing troff at the
macroscopic level, but not necessarily identical at the command
level. That is, it should be possible to write macros identical
with ms or me or whatever so that most documents can be formatted
without change on either system. However, some of the commands
which I felt were given wrong or clumsy semantics in troff I've
altered slightly.
The project is still only at the conceptual stage. The
purpose of this note is to solicit other comments on what troff
does badly and how a newer system might improve things without
making too radical a change. What follows are my ideas on
various topics.
Fonts
There should be essentially an infinite (at least 20 or 30)
number of fonts. The commands bd, cs, ul, and uf are eliminated,
since these can be produced by an appropriate sequence in font
tables. (The command cu is retained, since in filled and
justified mode it is difficult to produce the desired effect just
with fonts).
Font tables are a little more general than they are now. Each
entry in the font table specifies the character (as a number),
the width of the character, the TYPE of the character, and the
character information. (Several years ago I looked at some of
the SCRIBE internal tables, and I believe this is somewhat
similar to what is done there, although my memory is dim on the
particulars). There are three TYPES of characters. The first
type is just a single character for character translation - If
you want an 'a', print an 'a'. The second type is a string - if
you want an 'a', print the following sequence (the characters are
transmitted directly to the output, and are not processed by
broff). The third type is also a string, but is reprocessed by
broff - if you want an 'a' print \fWx\fPwyz.
Example
- 1 -
141 1 1 a
142 7 2 abcdefg
143 3 3 \fIabc\fP
This generality would permit users to make "virtual fonts",
for example fonts where the actual characters are from various
other fonts, etc.
Environments
Here is a major change from troff. In broff, environments can
be named and there can be any number of them. Furthermore,
environments are named (two character name) rather than numbered.
Finally, attributes that are not defined in an environment are
inherited from the outside, rather than having all attributes
defined in all environments.
There are two new commands for defining environments. The dv
command starts the definition of a new environment. It is
typically followed by a list of environment setting commands:
Example:
.dv XE
.ls 3
.po 2i
.ps 14p
.vs 16p
..
The av command appends to an environment. The ev command then
pushes the current environment, resets those attributes
associated with the named environment, inheriting all other
attributes from the previous environment. Setting environmental
parameters inside an ev does not effect the definition of the
environment.
Initializations
The troff manual lists initial values for almost all
environmental parameters. Almost all of these have been
eliminated (the one exception is the command character, which is
initialized to '.'. It would be kinda hard to bootstrap without
that). Instead, there is a file of broff commands associated
with every device. Prior to reading macros or source files, this
file is read to initialize such values as point size, font
positions, page length, page offset, line length, indent, escape
character, and nonbreak control character. It might also set
various conditions (see below).
Conditions
Currently, there are four named conditions in troff (even and
odd pages, nroff and troff). For many systems, this is just too
coarse. For example, we run two different versions of nroff (lpr
and spinwriter) and two different versions of troff (versatec and
- 2 -
typesetter). It would be nice to have an easy way for macros to
determine on what kind of device they are being used. I
therefore propose that the e and o conditions be kept, but that
all other letters be free to be set by the user (or in a device
initialization file, above). To do this, there would be a new
command ".dc c value". values would be unsigned integers (no
units).
It is not clear to me that the distinction between nroff and
troff need be kept. It seems to me that there is more of a
continuum of devices between a line printer and a typesetter.
Perhaps nroff is just troff on a device with few capabilities.
Any thoughts on this?
Point sizes, spacing ,etc.
Point sizes, vertical spacing, line spacing, etc would be
continuous up the the resolution of whatever your basic unit is.
It would be up to the postprocessor to make whatever restrictions
might be necessary for a particular device (rounding the point
size down to one of a few set values, or whatever).
Misc
The .pi command is eliminated. Has anybody ever found a use
for this?
A blank line now invokes the paragraphing macro. The
paragraphing macro is specified by the command ".pg XX", and is
associated with the current environment. pg with no arguments
means blank lines stay blank lines.
The command c2 has been changed to cn.
Please Mail me whatever comments you might have.
Tim Budd - {mcnc teklabs cornell purdue kpno} | arizona | budd
- 3 -
More information about the Comp.unix.wizards
mailing list