Confirming.

$ rpm -qf `which xman`
XFree86-tools-4.2.0-72

xman is a legacy application which is provided in the default XFree86 install,
but is not supported.  Please report this problem to XFree86.org by emailing
xfree86  It is likely that this application is unmaintained now,
and may contain any number of bugs.  I'll likely remove it from my next
build as there are other GUI manpage viewers in the distribution.

Well, while I'm opposed to any major vendor not supporting "legacy" applications
from the XFree86 project, on the grounds that these applications are still
industry standard, and in many cases, still much better than their supposed
"replacements" from GNOME or KDE (even if their interfaces aren't quite as
pretty), if you're going to insist on such a policy, it's fine as long as it's
easy to find out what those replacements are.

So, what are they?  Assuming they're installed on my system, they don't seem to
have man pages, which makes it very difficult to identify them.

I would like to comment that, when supporting a mix of Linux and commercial Unix
environments, it is important for "legacy" X apps to work, in order to provide a
uniform environment for the users, since in many cases GNOME or KDE apps are not
an option on those platforms (or are prohibitive to build and make available). 
It's great for Linux to have a nice, pretty desktop environment, but the fact of
the matter is that many sites using Linux in more places than just the back room
are Unix shops, and are going to expect their Linux desktops to work like their
Unix workstations.  This means they expect "legacy" applications on Linux
systems to work properly.

It seems as though you're the only person supporting X at Red Hat, which is
unfortunate.  You obviously have too much to do, if that's the case.  But for
Red Hat to have a policy of not supporting "legacy" X applications is a cheesy
cop-out which is probably going to irritate a lot of people...  If it means that
these apps are going to start disappearing from the distribution, it will likely
mean that I will have to start looking at alternatives to Red Hat where I
support Unix on the desktop.

People like the older X apps, often even when newer, prettier alternatives from
the desktop projects are available, because:

 - they're accustomed to them, from working with them for decades
 - they often perform better than their GNOME or KDE counterparts (like xterm)
 - they are often more flexible and configurable, via X resources

Before GNOME or KDE can really replace these apps in the eyes of many
experienced Unix users, they need to address at least point #2, and preferably
point #3 as well.  I realize this isn't in your realm of control, but until that
happens, many people will not be satisfied with GNOME or KDE replacements.  They
simply (often) don't work as well or as flexibly, no matter how pretty they may be.

Oh, also I will report the bug to the XFree86 team, as you suggested.  If I
receive any useful information back from them as a result, I'll keep this bug
updated with such.

Rather than responding to your lengthy comment above, I'll suffice to say,
that if upstream fixes xman, or if someone provides a patch to upstream
which get's accepted and commited to CVS, I'm happy to re-enable xman.

This issue is extremely unimportant however priority-wise in relation to
the hundreds of other open bug reports, so I'd be lying to you if I said
I'd even attempt to debug it anytime soon.  Reporting it upstream is the
fastest way to finding a solution.

Actually this seems to be related to a change in groff, rather than a problem
per se with xman...  

I have a RH 7.2 system, against which I compared the operation of xman from Red
Hat 8.  On both systems, xman formats its man pages using the following sequence
of commands:

gzip -d -c /usr/share/man/manX/manpage.X.gz > /tmp/tempfile
cd /usr/share/man; soelim /tmp/tempfile | geqn |gtbl | groff -Tlatin1 -mandoc >>
/tmp/othertmpfile 2>/dev/null

On Red Hat 8, the output of these commands (i.e. the contents of
/tmp/othertmpfile) produces terminal control sequences.  On 7.2 (and I believe
all versions of Red Hat prior to 8.0), it produces output like this:

CAL(1)                  System General Commands Manual                  CAL(1)

N^HNA^HAM^HME^HE
     c^Hca^Hal^Hl - displays a calendar

S^HSY^HYN^HNO^HOP^HPS^HSI^HIS^HS
     c^Hca^Hal^Hl [-^H-m^Hmj^Hjy^Hy1^H13^H3] [[_^Hm_^Ho_^Hn_^Ht_^Hh]
_^Hy_^He_^Ha_^Hr]

D^HDE^HES^HSC^HCR^HRI^HIP^HPT^HTI^HIO^HON^HN
     C^HCa^Hal^Hl displays a simple calendar.  If arguments are not specified,
the cur­
     rent month is displayed.  The options are as follows:

     -^H-1^H1      Display single month output (use if cal was built with -3 as
             default to get older traditional output)

     -^H-3^H3      Display prev/current/next month output (use if cal was built with
             traditional -1 as default to get newer improved output)

     -^H-m^Hm      Display Monday as the first day of the week.  (The default is
             Sunday.)

     -^H-j^Hj      Display Julian dates (days one-based, numbered from January 1).

     -^H-y^Hy      Display a calendar for the current year.

     A single parameter specifies the year (1 - 9999) to be displayed; note
     the year must be fully specified: ``cal 89'' will _^Hn_^Ho_^Ht display a
calendar
     for 1989.  Two parameters denote the month (1 - 12) and year.  If no
     parameters are specified, the current month's calendar is displayed.

     A year starts on Jan 1.

     The Gregorian Reformation is assumed to have occurred in 1752 on the 3rd
     of September.  By this time, most countries had recognized the reforma­
     tion (although a few did not recognize it until the early 1900's.)  Ten
     days following that date were eliminated by the reformation, so the cal­
     endar for that month is a bit unusual.

H^HHI^HIS^HST^HTO^HOR^HRY^HY
     A c^Hca^Hal^Hl command appeared in Version 6 AT&T UNIX.

BSD                              June 6, 1993                              BSD


This is clearly the format expected by xman, as xman on 7.2 works perfectly. 
So, it appears that groff on RH8 is producing terminal control sequences when it
should not be.  My guess (off the top of my head, without looking at the groff
code) is that it's supposed to behave differently if the output is being sent to
a terminal than if it is not, and someone mistakenly removed the check to see if
the output file descriptor is a terminal.

I think this needs to be reopened and reassigned to whoever is in charge of groff...

Well, I have to rule out my theory above...  I used the following command:

  $ man cal | cat > tmpfile

The contents of tmpfile included the backspace method of underlining and bolding
text, rather than terminal control sequences.  So it's apparently not as simple
as different behavior when the output is a terminal or not, as it works at least
sometimes.  But it still seems to be a problem with groff (or perhaps one of its
components, i.e soelim, geqn, or gtbl).

Ok, it looks like this would have to be fixed in xman after all...  I've tracked
down the problem.

On systems using groff >= 1.18, xman is broken.  Newer versions of groff now use
"SGR escape sequences" by default, rather than ^H sequences, for underlining and
enboldening text.  In order to get the old behavior (compatible with xman), you
must call groff with the -c option.

See http://groff.ffii.org/ for details.

For such systems, the following patch should suffice to fix the
problem.  Ideally, this should probably get some sort of configurable
define, but I don't want to guess how the X team would want to go
about dealing with this...

# diff -u oldvendor.h vendor.h
--- oldvendor.h 2003-01-08 13:30:08.000000000 -0500
+++ vendor.h    2003-01-08 13:33:02.000000000 -0500
@@ -173,7 +173,7 @@
 # elif defined(BSD) && (BSD >= 199103)
 #  define FORMAT "| eqn | tbl | nroff -man"
 # elif defined(linux)
-#  define FORMAT "| geqn | gtbl | groff -Tlatin1 -mandoc"
+#  define FORMAT "| geqn | gtbl | groff -c -Tlatin1 -mandoc"
 # else
 #  define FORMAT "| neqn | nroff -man"      /* The format command. */
 # endif


Mike, his tiny patch can easily be added to your existing manconf patch -- it
even patches the same file.

For others who are tracking this bug, there is another workaround in the mean
time.  In your .bashrc, .profile, or some similar file, include the line:

  export GROFF_NO_SGR=1

For original Bourne shells, this would of course need to be:

  GROFF_NO_SGR=1; export GROFF_NO_SGR

Cheers.

Note: I have reported this to the XFree86 team as well...  Hopefully they'll fix
it upstream.

IMHO, there should be some runtime method of determining how to call
groff.  Otherwise it is rather impossible to have on XFree86 binary
package set work on more than one distribution, and even the source
code would require tweaking an option for one version of groff and not
another.

I consider it to be a groff bug, if the behaviour changes this much
in between versions without changing the command line options.  I have
carbon copied our groff maintainer Florian Laroche for comment.

Derek,

Just giving some positive feedback - above described fix works for me also.
$ export GROFF_NO_SGR=1  

I had originally posted in the Red Hat install list (jhijr: "xman 
shows control characters"). Since I only receive the digest, my cut-and-paste 
replies often don't continue the thread, i.e. end up as separate entries in the 
archives. So I'm following up here.

Thanks,
John Ingersoll, Jr.

I'm leaving the official solution to this up to the XFree86 team.
Whatever they decide to put into XFree86 4.3.0 will be incorporated
into our source tree once the 4.3.0 release is made public.

I am defering this issue until the 4.3.0 release, after which time
you may feel free to reopen this from it's "DEFERRED" status.

xman is disabled in current builds, closing WONTFIX