Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 May 2015 02:02:11 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        current@FreeBSD.org
Subject:   [RFC] Replace gnu groff in base by heirloom doctools
Message-ID:  <20150514000211.GA9410@ivaldir.etoilebsd.net>

next in thread | raw e-mail | index | archive | help

--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom
doctools.

This mostly concern documentation in share/docs and the fallback when mando=
c(1)
is not able to render a manpage.

Heirloom doctools has progressed a lot recently and is now able to render
correctly all the document we do provide in base, it has active development=
 and
integrate quickly new features.

Upstream have been very reactive to bug report I have sent to them and fixed
them very quickly.

Heirloom has multiple advantages over GNU groff:
- it is partially CDDL partially BSD license.
- it is mainly written in C (to the exception of a single tool in C++ which=
 I do
  not plan to important)
- it is derived from the original macros from AT&T (in particular ms(7))
- it is smaller than GNU groff
- it has better unicode support than GNU groff
- it has better error reporting than GNU groff (which allowed me to fix a c=
ouple
  of the documentation there)
- heirloom manpages are mandoc(1) friendly which is not the case for GNU gr=
off's
  one

I do only plan to incorporate part of it and keeping our own version of too=
ls we
already have like: col(1), soelim(1), checknr(1) and vgrind(1).

mandoc(1) is still the target for rendering manpages and but I think keepin=
g a
fully functionnal roff(7) toolchain part of the base system is very good on=
 a
unix.

The issue we have with GNU groff is that newer version are in GPLv3 so we
cannot upgrade base version to a newer version. Base version of GNU groff i=
s a
stripped down version of GNU groff so users willing to user some extra
functionnality of GNU groff will have to rely on the ports tree.

what have already been done:
- col(1): updated and fixed  base on work with the heirloom doctools and
collaboration with OpenBSD folks. While there I have already sandboxed
col(1) using capsicum.
- checknr(1): now handles more roff(7) commands.
- vgrind(11): modernize code base and synchronized some changes from NetBSD

I plan to import heirloom doctool later this month.

So far the only issue we have is with documents using pic(1) when rendering=
 in
ascii (postscript and pdf rendering are ok) upstream is working on a fix bu=
t I
do not consider this as a blocker.

Allowing to have both gnu groff and heirloom at once switchable via an opti=
on
will be hard so I plan to make the switch happening at once.

=46rom 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 ex=
tra
care is needed please share it.

Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools

Best regards,
Bapt

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlVT5gMACgkQ8kTtMUmk6EzsjgCbBOa7l+MqICrMAGWGxyCkaxAI
afoAn36vmByJ9NHDKQoAgiicHO1KCJbS
=5btX
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--



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