Skip Menu |

This queue is for tickets about the podlators CPAN distribution.

Report information
The Basics
Id: 98199
Status: resolved
Priority: 0/
Queue: podlators

People
Owner: RRA [...] cpan.org
Requestors: aab [...] purdue.edu
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 4.07



CC: aab [...] purdue.edu
Subject: Bug(?) in roff generated by Pod::Man/pod2man -
Date: Wed, 20 Aug 2014 01:48:43 -0400 (EDT)
To: rra [...] stanford.edu, bug-podlators [...] rt.cpan.org
From: Paul Townsend <aab [...] purdue.edu>
Cygwin groff 1.22.2 perl 5.14.2 Pod::Man 2.25 pod2man --quotes=none Show quoted text
> cat Z
=head1 NAME tar - A file archiver tool, version 1.27.1 =head1 SYNOPSIS The GNU B<tar> program is invoked as either one of: =over 2 =item C<tar I<option>... [I<name>]...> =item C<tar I<letter>... [I<argument>]... [I<option>]... [I<name>]...> =back Show quoted text
> cat script
#!/usr/bin/env bash X=$1 cat $X pod2man --quotes=none $X >$X.man sed -e '1,/^\.TH/d' $X.man # to display pertinent portion of roff file nroff -man -c $X.man | less # the "..." are underlined in `less's output. Shouldn't be. sed -e '/^\.ie n \.IP/s,\\f(CW,\\fP,g' $X.man >$X.man2 # replace \f(CI -> \f(CW with \f(CI -> \fP nroff -man -c $X.man2 | less # the "..." are NOT underlined in `less's output. This is correct. Show quoted text
> script Z # should give examples for comments below.
1) The "..."s should not end up being underlined. I'm not sure why because each italic sequence, \f)CI, is terminated with a \f(CW font change. groff is confused maybe? 2) The font shifts into a new font (\f(CI = italic) are terminated by \f(CW. If I remember correctly from way back when, the \f font change mechanism is implemented as a LIFO queue. The way it's being done by Pod::Man could create a rather large queue at the end of the document not to mention that the resulting font being used after processing those lines approaches being indeterminate. To get around this, the second of each \f pair should be a \fP (revert to the previous font). At the end of processing those lines, nroff/troff should be using the font the was being used before those lines were encountered. 3) The \fR at the end of the troff line should not be there. You don't know that the user actually wants the Roman font. Again \fP. 4) If the \f(CW -> \fP, \f(CI -> \fP sequences were used, I think you could get away with the same roff line for both nroff and troff. Note that \f(CW -> \f(CI -> \fP -> \fP is legal, i.e., you can embed the \f pairs. -- Thanks, -- Paul Townsend
Subject: Re: [rt.cpan.org #98199] Bug(?) in roff generated by Pod::Man/pod2man -
Date: Tue, 19 Aug 2014 23:01:22 -0700
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Quick reply. I haven't looked at any of the additional details yet. "Paul Townsend via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> To get around this, the second of each \f pair should be a \fP (revert > to the previous font).
Unfortunately, this doesn't always work on at least Solaris 2.6: # Unfortunately, there is a bug in Solaris 2.6 nroff (not present in GNU # groff) where the sequence \fB\fP\f(CW\fP leaves the font set to B rather # than R, presumably because \f(CW doesn't actually do a font change. To work # around this, use a separate textmapfonts for text blocks where the default # font is always R and only use the smart mapfonts for headings. Show quoted text
> 4) If the \f(CW -> \fP, \f(CI -> \fP sequences were used, I think you > could get away with the same roff line for both nroff and troff. Note > that \f(CW -> \f(CI -> \fP -> \fP is legal, i.e., you can embed the \f > pairs.
Another comment in the source explains why things are done this way: # When building up the *roff code, we don't use real *roff fonts. Instead, we # embed font codes of the form \f(<font>[SE] where <font> is one of B, I, or # F, S stands for start, and E stands for end. This method turns these into # the right start and end codes. # # We add this level of complexity because the old pod2man didn't get code like # B<someI<thing> else> right; after I<> it switched back to normal text rather # than bold. We take care of this by using variables that state whether bold, # italic, or fixed are turned on as a combined pointer to our current font # sequence, and set each to the number of current nestings of start tags for # that font. # # \fP changes to the previous font, but only one previous font is kept. We # don't know what the outside level font is; normally it's R, but if we're # inside a heading it could be something else. So arrange things so that the # outside font is always the "previous" font and end with \fP instead of \fR. # Idea from Zack Weinberg. So at least when I wrote that (which was back when I had Solaris to test on), I was pretty sure that only one level of font was retained. Unfortunately, I don't have access to those platforms any more. Maybe we can now assume that behavior? -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Apologies for how long it took me to address this bug. I didn't fix all of the things that you mentioned -- in particular, I didn't try to unify groff and nroff code for headings, and I didn't try to keep the size of the font stack low by using \fP more. Both of those changes were to work around bugs in Solaris 2.6, and since I don't have access to that platform any more to check whether they would be regressions, I'm hesitant to mess with that code, and no one has reported any actual formatting issues from those workarounds. I did, however, find and fix the specific issue that you reported, which was an incomplete elimination of fixed-width font usage for nroff, and now italics should be turned off properly.