groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] surprise, surprise


From: Ted Harding
Subject: Re: [Groff] surprise, surprise
Date: Sun, 02 Sep 2001 18:49:40 +0100 (BST)

On 02-Sep-01 Ralph Corderoy wrote:
> Hi Werner,
> 
>> I fear we won't agree on this point.  Maybe this is the conflict
>> between young and old -- I've never used UNIX troff...
> 
> Aha, you might have something there.  Those that like troff for what it
> is compared with those that think of what it might have been  :-)
> 
> We'll agree to disagree.
> 
> Cheers,
> 
> 
> Ralph.
> 
> PS.  Who're you calling young?

Well, I dare not intervene on that last point.

I'd like to give a few more views, and ask a question.

1. Personally, I am not particularly fussy whether groff
   treats \fB.test\fP as hiding the "." at the start of
   the line. What has bothered me in this discussion is
   the discovery that apparently "UNIX troff" has the
   same behaviour. We then come up against "ethical" issues
   about compatibility.

   I think someone taking the "Troff User's Manual" (TUM)
   as terms of reference and writing a program to achieve
   what it describes would, very probably, wrote one which
   behaved as Werner expected (and as I did, long ago).
   In fact, I can see little point in making "\fB" et al
   "transparent". Can anyone?

2. The following view may strike some as a bit heretical,
   but like all heresies it has its point.

   James Clark's original project (as I understand it)
   was to create a GNU version of "UNIX troff". In due
   course this incorporated so many extensions and
   improvements that it was in effect a new program.
   The "-C" flag was put in to make it behave like the
   old one. Nevertheless, even "UNIX troff" had moved
   on, especially in commercial variants.

   For instance, 1992 troff allowed \C'charname' for
   a character name of arbitrary length (not in the original).
   SoftQuad troff (SQtroff, colloquially "squitroff")
   which came out in the early 1980s, allowed long names
   referenced as in "\n{longname}", or long-named macros
   referenced as ":longname" (no-break version ";longname"),
   and so on.

   A view I have been keeping to myself for some time is
   that "groff" should not be considered "GNU troff".

   I agree with Ralph: "troff is troff". And I also say
   groff  is groff. The reason old (in the sense of "ancien",
   Werner) troff users like groff is that groff does
   things on basically the same principles as troff, from
   the user's point of view. And we like that. But they
   are not the same program.

   Nor, as far as I can see, are "UNIX troff" and "groff -C"
   exactly the same program either. See the section
   "Incompatibilities" in "man troff", and also see the
   comments on ".cf".

   So maybe there should be two programs: GNU troff, and groff.
   GNU troff would be the GNU implementation of UNIX troff,
   and could be used without soul-searching by people who
   still have old troff files which need formatting.

   Groff, on the other hand, could then feel free to become
   what it naturally should become. I have a strong feeling
   that the need for "UNIX troff compatibility" has constrained
   the development of groff on some fronts.

3. And now for the question. In the above mentioned "man troff"
   section on Incompatibilities, only the first paragraph
   explicitly states what the effect of "-C" is, namely to
   disallow long names (and enable interpretation of ".abcde"
   as ".ab cde"; and this is all that is stated under ".cp"
   as well).

   For all the other incompatibilities listed under "Incompatibilities",
   (".ps 10u", differences between unformatted input characters
   and formatted output characters, etc) it is not explicitly stated
   whether these are still incompatibilities in compatibility
   mode.

  So: Are there incompatibilities between "groff -C" and "UNIX
  troff" and, if so, which are they? I have had so very little
  need to use groff in "compatibility" mode that I have never
  done the experimentation needed to establish any of this.

Comment: If there are incompatibilities between "groff -C"
and "UNIX troff", this strengthens the case for two separate
programs! That way, "GNU troff" can set about being fully
compatible, and groff can stop worrying about it!

By the way: Plan-9 troff source presumably compiles to a truly
compatible "UNIX troff"; at any rate the "Troff Users Manual"
that goes with Plan-9 troff seems to be almost identical to
the UNIX one. But I suppose that the Plan-9 "licence" is
incompatible with GNU's GPL.

Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 02-Sep-01                                       Time: 18:49:40
------------------------------ XFMail ------------------------------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]