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