Hi Ingo,
First of all, thanks a lot for the quick and very helpful answer despite
my weak report.
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...
>
> > I noticed that the djview4(1) man page contains lots of artefacts
> > stemming from an incorrect rendering of tables, as in the paragraph
> > below:
> >
> > ----- 8< -----
> > center,box; lfI l lfB l lfB l lfB l lfB l
> > number Magnification factor in range 10% to 999%.
> > one2one Select the "one-to-one" mode. width Select the
> > "fit width" mode. page Select the "fit page" mode.
> > stretch Stretch the image to the plugin window size.
> > ----- >8 -----
> >
>
> That happens because the page doesn't contain the standard
> annotation telling groff(1) that it needs tbl(1).
>
I see. This makes sense, so there is as clean a solution as I hoped
there to be.
> > when one lets it compile with `groff -Tascii' without the `-t' option
> > for preliminary tbl(7) rendering.
>
> Yes, that is what pkg_create(1) ends up doing, and i can't blame it.
This makes sense, too, given that there is such an annotation.
> > The artefacts are irritating, but I'm not sure if the result of
> > `groff -t -Tascii' is preferable since it confuses less(1) and more(1)
> > at least in uxterm(1) in that the resulting terminal escapes for bold
> > and italic fonts aren't rendered correctly either and produce other
> > irritating artefacts.
>
> Probably you forgot to use the -P-c option to groff.
If not knowing about it counts as forgetting :)
> Alternatively, you can run less(1) with the -R option.
About that one I forgot...
> 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
and
$ groff -t -Tascii djview4.1 | more
Adding the -R option to either less or more or adding the -P-c option to
groff in these two commands fixes the display problems for me.
> > I'm not sure whether this is a common problem and whether there is a
> > standard way of dealing with this kind of situation.
>
> I'd suggest pushing the following diff upstream, it fixes the
> issue.
That would surely be the best solution. Thanks a lot.
> Do you want me to commit it, too?
I tested your patch to the port using the ports testing guide in the FAQ
and encountered no new issues*, so if you could submit it, that would be
great.
The manual now looks the way it should, thanks a lot!
* The only thing I noticed is that
$ make clean
$ export SEPARATE_BUILD=Yes
$ make fake
fails (no issues with `$ make build' with SEPARATE_BUILD=Yes) but this
is independent of your patch. It spawns the following error message:
[...]
gmake[1]: Leaving directory '/usr/obj/ports/djview4-4.9/build-amd64/src'
cd nsdejavu && gmake
gmake[1]: Entering directory '/usr/obj/ports/djview4-4.9/build-amd64/nsdejavu'
eval `grep '^dlname=' nsdejavu.la` && \
echo ${dlname} | sed -e 's/\([-.][0-9][0-9]*\)*//g' > nsdejavu.x
grep: nsdejavu.la: No such file or directory
Makefile:65: recipe for target 'nsdejavu.x' failed
gmake[1]: *** [nsdejavu.x] Error 2
gmake[1]: Leaving directory '/usr/obj/ports/djview4-4.9/build-amd64/nsdejavu'
Makefile:60: recipe for target 'all-nsdejavu' failed
gmake: *** [all-nsdejavu] Error 2
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2768
'/usr/obj/ports/djview4-4.9/build-amd64/.build_done')
*** Error 1 in /usr/ports/graphics/djview4
(/usr/ports/infrastructure/mk/bsd.port.mk:2493 'fake')
$
Best wishes,
Theo
