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

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote:
> 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.

Lots of work has been done recently on heirloom in particular regarding
the support of mdoc(7) and I have opened tickets for all issues I could find and
they have been fixed. Please point me to issues you can have regarding mdoc(7).

(Note that I'm speaking of doctools as of latest git, not latest release)

> 
>  |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.

Can you tell me more about the macros you do use and a sample document so I can
check and see if we can add support for it?
> 
> 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.

As I said you will be able to use groff from ports. I do not claim that n-t-r is
a replacement for groff in general I propose it for a replacement for groff in
base.

groff in base is stuck at 1.19.2 version while upstream is at 1.22.3 version
which in particular has a couple of fixes for mdoc(7) format and a bit more.

Every user of groff will have huge benefit using newer groff versions: bug
fixes, full functionnalities available etc.

Best regards,
Bapt

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlVbWJUACgkQ8kTtMUmk6EwfgACffQVe3m1VmKEQjbnxUsOWR7ZO
vaoAoJPyYye2U0UATzlsUfl2Vb1p/dNZ
=f+5w
-----END PGP SIGNATURE-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150519153654.GC52236>