Re: [RFC] Replace gnu groff in base by heirloom doctools
On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote: Hi Bapt current@ I think keeping a fully functionnal roff(7) toolchain part of the base system is very good on a unix. Yes, Unix has always also been a tool to get jobs done (aka PWB), as well as merely recompile more Unix. Ditto FreeBSD. 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. Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Regression tests that use public BSD source data to build more BSD are a good start, but just a start, insufficient to discover all problems. There's non public user data sets to consider. Many users won't read current@, just announce@, so before removal hits a Release, we need a one Release warning, ie This is the last Release before old functionality goes. Assume lots of user data will Not be compatible with heirloom-doctools users wont know to start checking their data, until they see an announcement in the next Release. Those users would be able to use groff from ports and then have the benefit of a more up to date version of groff and a groff with more functionnality than the castrated version we do have in base while compatible. We'll need a copy of same version of existing tools, macros etc, copied out unchanged to a port or meta port so users affected have a lifeboat. groff is already in ports. User data Will break: (My groff usage frequently broke when groff changed: I use groff for CV, business card, letters, invoices, personal, with embedded pics, scaled offset figures, tables, fonts, sizes, ouput in all of txt ps pdf pcl html output.) Solved by using groff from ports. Unfortnately I have'nt time to help test with my data as FreeBSD already eats too much time, shoving bind from src to ports (+planning to dump bind move on) + ripping majordomo acroread out of ports, all of which I need must restore before upgrading servers workstations. Changes would need maximal warning minimum disruption please. Groff in base is rottening for various reasons and lacks lots of the features provided by a full groff. Using groff from ports is a win for user realying on groff specific toolchain. Heirloom in base is a win over groff because it has better support for roff(7) better font handling etc. Best regards, Bapt pgpVQk6eIduim.pgp Description: PGP signature
Re: [RFC] Replace gnu groff in base by heirloom doctools
Baptiste Daroussin b...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Aw: Re: [RFC] Replace gnu groff in base by heirloom doctools
Steffen Nurpmeso sdao...@yandex.com wrote: 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. This is not completely true. It is usable, I did check it with all about 7000 manpages in the base of OpenBSD. But it does indeed also require further work. Please note that FreeBSD uses mandoc(1) for formatting manpages. Groff in the base (or a replacement) is only a fallback. 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. Please make a bug report ;) 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. The groff version in the base is quite old and is there to have a *roff toolchain in the base and as a fallback solution for mandoc(1). If one does serious typesetting (and wants to use groff) it is recommended to use the up-to-date version from ports. Carsten ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote: Baptiste Daroussin b...@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 pgp8dJYKiJyrI.pgp Description: PGP signature
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Tue, May 19, 2015 at 06:52:40PM +0200, Steffen Nurpmeso wrote:
Hello,
Baptiste Daroussin b...@freebsd.org wrote:
|On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote:
| Baptiste Daroussin b...@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).
.Ns doesn't work right, so is why this strong emphasis of mine in
the first sentence. Carsten has this example of mine (last week):
.Dd Apr 30, 2015
.Dt xxx 1
.Os
.Sh NAME
.Nm xxx
.Nd yyy
.
Read the system mailbox of
.Ar user
(appropriate privileges presumed), and
.Dq assume to be
.Ar user
in some aspects, e.g. in respect to
.Ic file Ns
\(enexpansions of
.Ql %
etc.; also see
.Ev USER .
Thanks I will have a look at it soon
|(Note that I'm speaking of doctools as of latest git, not latest release)
As of last week right shortly after your mail i guess it was.
||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?
Well Carsten asked me this too last year and i've given him as
much as i could. But the macros are really rather simple layout
via traps. If i recall correctly the examples i've shown Carsten
where letters. I would have to rewrite the macros before i can
make them public, but it is pretty normal troff stuff with
traps and positioning, like e.g. the context-free following, for
an example (i think i have sent Carsten some trap info back then?)
.MACRO RECEIVER
. S:BOOLIFY \\$1
. ie \\n[S:#IS_BOOL] \{\
. vs \\n(.su*\\*[RECEIVER_LINE_SPACING_SCALE_FACTOR]
. nf
. de S:RECEIVER_TRAP EOT
.blm PARA
.ds S:RECEIVER_DIVERSION_HOOK
.sp 1v
\\*[RECEIVER_PREHOOK]\c
.EOT
. di S:RECEIVER_DIVERSION
. blm S:RECEIVER_TRAP
. \}
. el \{\
. if d S:RECEIVER_DIVERSION_HOOK \{\
\\*[RECEIVER_POSTHOOK]\c
.rm S:RECEIVER_DIVERSION_HOOK
. \}
. di
. \ Calculate best position for address field and box out
. if (\\n(dnu \\n[#RECEIVER_HEIGHT]u) \{\
.WARNING \
\\$0 address does not fit in address window! Growing window!!
.nr #RECEIVER_HEIGHT \\n(dnu
. \}
. nr #1 (\\n[#RECEIVER_HEIGHT]u-\\n(dnu)/2u
. sp |(\\n[#RECEIVER_START]u+\\n(#1u
. rr #1
. S:RECEIVER_DIVERSION
. rm S:RECEIVER_DIVERSION
. rm S:RECEIVER_TRAP
. fi
. vs
. \}
..
Pretty clean letter stuff like that it is. (You asked for an
example.)
Same I'll have a look :)
| 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 \
I will have my own one, then. Enough work for getting old. d^.^b
|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.
The mdoc(7) macros are BSD licensed. Nothing prevents anyone from
taking those from GNU troff [master] branch and integrating them
into their own roff version. I did that for (the one that will
be) mine.
|Every user of groff will have huge benefit using newer groff versions: bug
|fixes, full functionnalities available etc.
The above macros originate from stuff written under FreeBSD 4.9
and especially 5.3 and ran almost a decade there, very smoothly.
Also i'm not so sure about that huge when i compare groff
Re: [RFC] Replace gnu groff in base by heirloom doctools
Hello,
Baptiste Daroussin b...@freebsd.org wrote:
|On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote:
| Baptiste Daroussin b...@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).
.Ns doesn't work right, so is why this strong emphasis of mine in
the first sentence. Carsten has this example of mine (last week):
.Dd Apr 30, 2015
.Dt xxx 1
.Os
.Sh NAME
.Nm xxx
.Nd yyy
.
Read the system mailbox of
.Ar user
(appropriate privileges presumed), and
.Dq assume to be
.Ar user
in some aspects, e.g. in respect to
.Ic file Ns
\(enexpansions of
.Ql %
etc.; also see
.Ev USER .
|(Note that I'm speaking of doctools as of latest git, not latest release)
As of last week right shortly after your mail i guess it was.
||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?
Well Carsten asked me this too last year and i've given him as
much as i could. But the macros are really rather simple layout
via traps. If i recall correctly the examples i've shown Carsten
where letters. I would have to rewrite the macros before i can
make them public, but it is pretty normal troff stuff with
traps and positioning, like e.g. the context-free following, for
an example (i think i have sent Carsten some trap info back then?)
.MACRO RECEIVER
. S:BOOLIFY \\$1
. ie \\n[S:#IS_BOOL] \{\
. vs \\n(.su*\\*[RECEIVER_LINE_SPACING_SCALE_FACTOR]
. nf
. de S:RECEIVER_TRAP EOT
.blm PARA
.ds S:RECEIVER_DIVERSION_HOOK
.sp 1v
\\*[RECEIVER_PREHOOK]\c
.EOT
. di S:RECEIVER_DIVERSION
. blm S:RECEIVER_TRAP
. \}
. el \{\
. if d S:RECEIVER_DIVERSION_HOOK \{\
\\*[RECEIVER_POSTHOOK]\c
.rm S:RECEIVER_DIVERSION_HOOK
. \}
. di
. \ Calculate best position for address field and box out
. if (\\n(dnu \\n[#RECEIVER_HEIGHT]u) \{\
.WARNING \
\\$0 address does not fit in address window! Growing window!!
.nr #RECEIVER_HEIGHT \\n(dnu
. \}
. nr #1 (\\n[#RECEIVER_HEIGHT]u-\\n(dnu)/2u
. sp |(\\n[#RECEIVER_START]u+\\n(#1u
. rr #1
. S:RECEIVER_DIVERSION
. rm S:RECEIVER_DIVERSION
. rm S:RECEIVER_TRAP
. fi
. vs
. \}
..
Pretty clean letter stuff like that it is. (You asked for an
example.)
| 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 \
I will have my own one, then. Enough work for getting old. d^.^b
|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.
The mdoc(7) macros are BSD licensed. Nothing prevents anyone from
taking those from GNU troff [master] branch and integrating them
into their own roff version. I did that for (the one that will
be) mine.
|Every user of groff will have huge benefit using newer groff versions: bug
|fixes, full functionnalities available etc.
The above macros originate from stuff written under FreeBSD 4.9
and especially 5.3 and ran almost a decade there, very smoothly.
Also i'm not so sure about that huge when i compare groff
1.19.2-574-gecbf4f1 (which is the last GPL2 commit) and 1.22.3.
Also Carsten said that. Until now i have indeed assumed it is
purely rhetoric.
Out of interest: what do you mean when you say full
functionality? I see some improvements in the line breaking
algorithm and
Re: [RFC] Replace gnu groff in base by heirloom doctools
Hi Bapt current@ I think keeping a fully functionnal roff(7) toolchain part of the base system is very good on a unix. Yes, Unix has always also been a tool to get jobs done (aka PWB), as well as merely recompile more Unix. Ditto FreeBSD. 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. Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Regression tests that use public BSD source data to build more BSD are a good start, but just a start, insufficient to discover all problems. There's non public user data sets to consider. Many users won't read current@, just announce@, so before removal hits a Release, we need a one Release warning, ie This is the last Release before old functionality goes. Assume lots of user data will Not be compatible with heirloom-doctools users wont know to start checking their data, until they see an announcement in the next Release. We'll need a copy of same version of existing tools, macros etc, copied out unchanged to a port or meta port so users affected have a lifeboat. User data Will break: (My groff usage frequently broke when groff changed: I use groff for CV, business card, letters, invoices, personal, with embedded pics, scaled offset figures, tables, fonts, sizes, ouput in all of txt ps pdf pcl html output.) Unfortnately I have'nt time to help test with my data as FreeBSD already eats too much time, shoving bind from src to ports (+planning to dump bind move on) + ripping majordomo acroread out of ports, all of which I need must restore before upgrading servers workstations. Changes would need maximal warning minimum disruption please. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Thu, May 14, 2015 at 10:13:18AM +0100, David Chisnall wrote: On 14 May 2015, at 09:59, Baptiste Daroussin b...@freebsd.org wrote: On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: On 14 May 2015, at 01:02, Baptiste Daroussin b...@freebsd.org wrote: - it is partially CDDL partially BSD license. We currently have a WITHOUT_CDDL knob that some people use. If we don’t build the CDDL parts, what will break? Exactly the same thing that breaks right now WITHOUT_GNU and/or WITHOUT_CXX aka you won't have the main part of the toolchain (aka troff/nroff) But man pages will still work via mandoc? WITHOUT_GNU is known not to work (though we’re trying to address that with 11). WITHOUT_CDDL is generally expected to give a working system currently. Yes since I switched the default manpage renderer to mandoc(1) :) (meaning that WITHOUT_GNU is also not blocking manpage rendering) Best regards, Bapt pgp1CQvkz97MO.pgp Description: PGP signature
Re: [RFC] Replace gnu groff in base by heirloom doctools
On 14 May 2015, at 09:59, Baptiste Daroussin b...@freebsd.org wrote: On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: On 14 May 2015, at 01:02, Baptiste Daroussin b...@freebsd.org wrote: - it is partially CDDL partially BSD license. We currently have a WITHOUT_CDDL knob that some people use. If we don’t build the CDDL parts, what will break? Exactly the same thing that breaks right now WITHOUT_GNU and/or WITHOUT_CXX aka you won't have the main part of the toolchain (aka troff/nroff) But man pages will still work via mandoc? WITHOUT_GNU is known not to work (though we’re trying to address that with 11). WITHOUT_CDDL is generally expected to give a working system currently. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On 14 May 2015, at 01:02, Baptiste Daroussin b...@freebsd.org wrote: - it is partially CDDL partially BSD license. We currently have a WITHOUT_CDDL knob that some people use. If we don’t build the CDDL parts, what will break? David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: On 14 May 2015, at 01:02, Baptiste Daroussin b...@freebsd.org wrote: - it is partially CDDL partially BSD license. We currently have a WITHOUT_CDDL knob that some people use. If we don’t build the CDDL parts, what will break? Exactly the same thing that breaks right now WITHOUT_GNU and/or WITHOUT_CXX aka you won't have the main part of the toolchain (aka troff/nroff) Best regards, Bapt pgpERse66R4LX.pgp Description: PGP signature
Re: [RFC] Replace gnu groff in base by heirloom doctools
On May 13, 2015, at 17:02, Baptiste Daroussin b...@freebsd.org wrote: Hi, I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom doctools. … Hi Bapt, Do you have a list of items that require doctools [if groff isn’t present]? Thanks! -NGie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Thu, May 14, 2015 at 02:31:55AM -0700, Garrett Cooper wrote: On May 13, 2015, at 17:02, Baptiste Daroussin b...@freebsd.org wrote: Hi, I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom doctools. … Hi Bapt, Do you have a list of items that require doctools [if groff isn’t present]? Thanks! They are all only build time and all locate in share/docs basically everything using bsd.doc.mk man(1) also falls back on gnu groff when not able to read a manpage with mandoc and I will switch that to use heirloom (and if not present try to use gnu groff from ports) Best regards, Bapt pgp5F8KDOyC8C.pgp Description: PGP signature
Re: [RFC] Replace gnu groff in base by heirloom doctools
On 14 May 2015, at 10:24, Baptiste Daroussin b...@freebsd.org wrote: On Thu, May 14, 2015 at 10:13:18AM +0100, David Chisnall wrote: On 14 May 2015, at 09:59, Baptiste Daroussin b...@freebsd.org wrote: On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: On 14 May 2015, at 01:02, Baptiste Daroussin b...@freebsd.org wrote: - it is partially CDDL partially BSD license. We currently have a WITHOUT_CDDL knob that some people use. If we don’t build the CDDL parts, what will break? Exactly the same thing that breaks right now WITHOUT_GNU and/or WITHOUT_CXX aka you won't have the main part of the toolchain (aka troff/nroff) But man pages will still work via mandoc? WITHOUT_GNU is known not to work (though we’re trying to address that with 11). WITHOUT_CDDL is generally expected to give a working system currently. Yes since I switched the default manpage renderer to mandoc(1) :) (meaning that WITHOUT_GNU is also not blocking manpage rendering) Sounds good to me. Probably warrants a release notes entry specifically documenting that change, but otherwise sounds like a big improvement! David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Thu, 14 May 2015 02:02:11 +0200 Baptiste Daroussin b...@freebsd.org wrote 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 mandoc(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 ATT (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 couple of the documentation there) - heirloom manpages are mandoc(1) friendly which is not the case for GNU groff's one I do only plan to incorporate part of it and keeping our own version of tools 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 keeping 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 is 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 but I do not consider this as a blocker. Allowing to have both gnu groff and heirloom at once switchable via an option will be hard so I plan to make the switch happening at once. 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. Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Best regards, Bapt +1 Please do, and *thank you* for all the work you put into this! --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
+1 Great idea. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
