groff
[Top][All Lists]
Advanced

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

Re: [Groff] An environment variable for enabling compatibility mode


From: Werner LEMBERG
Subject: Re: [Groff] An environment variable for enabling compatibility mode
Date: Thu, 31 Jan 2002 23:11:24 +0100 (CET)

> Back in the `Surprise, Surprise' thread I raised the issue of a
> single compatibility flag being insufficient.
>
>     http://www.ffii.org/archive/mails/groff/2001/Aug/0085.html
>
> I still think that's the case because, as Jon said, we end up with
> documents that use some groff extensions, so we can't use -C, but we
> don't want them to break with future groffs.

Before we discuss further how to handle this problem within groff, I
want to know how other applications have solved this.  Can some of you
provide examples?

Secondly, I ask you to name features which have changed since groff
version 1.11 where you believe that the behaviour before the change
should be available.

> How about `naming' the pertinent compatibility issues and then only
> enabling extensions explicitly asked for?  groff could search in the
> command line, the environment, and a file for such a list, using the
> first one found.

I believe that all of these methods are error-prone and tedious to
use.  The only reliable way I can imagine is that the document itself
asks for a specific groff version.  Something like

  .groff-version xx.yy.zz

should be at the beginning.  Anyway, such a versioning command is not
sufficient; a user which has fine-tuned a document for printing *must*
preserve all used macro packages!  I'm quite sure that older macro
packages work without problems on recent versions of groff (probably
with an inserted `.groff-version'), so backwards compatibility is not
an issue.

For example, right now I'm changing the `I' macro of the man package
from

  .de1 I
  .  it 1 an-trap
  .  ft I
  .  if \\n[.$] \&\\$*
  ..

to

  .de1 I
  .  it 1 an-trap
  .  ft I
  .  if \\n[.$] \,\\$*\/
  ..

This really improves appearance if .I is used as usual.  However, in
case a user has explicitly inserted `\|' to get the same effect with
the old definition of .I, things will be looking worse.

> But first off, some agreement's needed that a single -C is
> insufficient.

The meaning of -C is quite restricted, providing compatibility with
UNIX troff *on the input syntax level*.  It has nothing to do with
groff's extensions; I fully agree that -C is not a means to control
which extensions are in use and which not.


    Werner

reply via email to

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