Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 May 2015 14:37:22 +0200
From:      Steffen Nurpmeso <sdaoden@yandex.com>
To:        Baptiste Daroussin <bapt@freebsd.org>
Cc:        current@freebsd.org, "Julian H. Stacey" <jhs@berklix.com>
Subject:   Re: [RFC] Replace gnu groff in base by heirloom doctools
Message-ID:  <20150519123722.KSZHLtTvPWw8%sdaoden@yandex.com>
In-Reply-To: <20150519112644.GB52236@ivaldir.etoilebsd.net>
References:  <20150514000211.GA9410@ivaldir.etoilebsd.net> <201505152342.t4FNgRgq076946@fire.js.berklix.net> <20150519112644.GB52236@ivaldir.etoilebsd.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Baptiste Daroussin <bapt@freebsd.org> wrote:
 |On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote:

 |>> I think keeping a fully functionnal roff(7) toolchain part of the
 |>> base system is very good on a unix.

 |>> From what I could check I cannot find any regression when \
 |>> migrating from gnu
 |>> groff to heirloom doctools, if there is a particular area \
 |>> when you think extra
 |>> care is needed please share it.

It seems you haven't checked at all.
It seems to me that e.g. mdoc(7) of n-t-r seems to require quite
a bit of work in order to be at all usable.

 |Heirloom in base is a win over groff because it has better \
 |support for roff(7)
 |better font handling etc.

The macros i use for myself don't work with n-t-r, too: once
i truly looked (a few months ago) i found that i would have to
rewrite all traps and other positioning in order to get that
right.

Despite that you seem to do what you want to do anyway, n-t-r is
possibly a usable troff, if you go its way and deal with it you
may be able to gain a bit nicer output _faster_ and without
converting your beloved special fonts first, but in no way is
n-t-r a _replacement_ for groff.
Ciao,

--steffen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150519123722.KSZHLtTvPWw8%sdaoden>