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>
next in thread | previous in thread | raw e-mail | index | archive | help
--hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > |>> I think keeping a fully functionnal roff(7) toolchain part of the > |>> base system is very good on a unix. >=20 > |>> 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. >=20 > 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 fin= d 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) >=20 > |Heirloom in base is a win over groff because it has better \ > |support for roff(7) > |better font handling etc. >=20 > 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? >=20 > 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 --hOcCNbCCxyk/YU74 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVbWJUACgkQ8kTtMUmk6EwfgACffQVe3m1VmKEQjbnxUsOWR7ZO vaoAoJPyYye2U0UATzlsUfl2Vb1p/dNZ =f+5w -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150519153654.GC52236>