Hi, fix committed. Alexandr, are you going to push it upstream? Thanks for checking, in any case.
Theo Buehler wrote on Tue, Nov 25, 2014 at 07:40:24AM +0100: > On Mon, Nov 24, 2014 at 10:49:11PM +0100, Ingo Schwarze wrote: >> Theo Buehler wrote on Mon, Nov 24, 2014 at 04:56:00PM +0100: >>> This is a groff(1)-related mail, so I'm not sure if CC'ing schwarze@ >>> is appropriate, if not, my apologies. >> I'm maintaining the groff port, so if you suspect a problem with >> groff, it is. > As you explained below, this wasn't really a problem with groff but > rather a problem with the man-page and in addition with a user very > unfamiliar with groff... That's OK, it's sometimes hard to distinguish problems using a tool from bugs in the tool. >> This is just a guess, of course, because you are not >> showing the actual commands you ran, nor hexdump(1) -C >> output of the result. > Sorry about that. As you probably suspected, I simply ran > $ groff -t -Tascii djview4.1 | less Ouch. The correct incantation can be found in /usr/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm method OpenBSD::PackingElement::Manpage::format() $ groff -t -mandoc -mtty-char -E -Ww -Tascii -P -c djview4.1 | less Or, if you want diagnostics, $ groff -t -mandoc -mtty-char -W all -Tascii -P -c djview4.1 | less Compared to mandoc(1), groff(1) does have a taste for options. If we manage to fix the last remaining issue in mandoc(1), which is the roff parser swallowing the line ".\n" even inside .TS, the equivalent mandoc(1) call is going to be: $ mandoc djview4.1 | less $ mandoc -W all djview4.1 | less Yours, Ingo
