Problems with Xnest.1x:

1. Ambiguous or invalid backslash.  This doesn't cause groff a problem.
but it confuses doclifter and may confuse older troff implementations.

--- Xnest.1x-orig	2007-01-14 11:20:14.000000000 -0500
+++ Xnest.1x	2007-01-14 11:20:23.000000000 -0500
@@ -142,12 +142,12 @@
 will probably have to temporarily quit the real window manager.  By
 default \fIXnest\fP will keep the nested client window whose colormap
 should be installed in the real server in the
-\fIWM\_COLORMAP\_WINDOWS\fP property of the top level \fIXnest\fP
+\fIWM_COLORMAP_WINDOWS\fP property of the top level \fIXnest\fP
 window.  If this colormap is of the same visual type as the root
 window of the nested server, \fIXnest\fP will associate this colormap
 with the top level \fIXnest\fP window as well.  Since this does not
 have to be the case, window managers should look primarily at the
-\fIWM\_COLORMAP\_WINDOWS\fP property rather than the colormap
+\fIWM_COLORMAP_WINDOWS\fP property rather than the colormap
 associated with the top level \fIXnest\fP window.  Unfortunately,
 window managers are not very good at doing that yet so this option
 might come in handy.
@@ -201,10 +201,10 @@
 different visual from the default visual of the nested server,
 \fIXnest\fP will put the top window of this nested client and all
 other top windows of the nested clients that use the same colormap
-into the \fIWM\_COLORMAP\_WINDOWS\fP property of the top level
+into the \fIWM_COLORMAP_WINDOWS\fP property of the top level
 \fIXnest\fP window on the real server.  Thus, it is important that the
 real window manager that manages the \fIXnest\fP top level window
-looks at the \fIWM\_COLORMAP\_WINDOWS\fP property rather than the
+looks at the \fIWM_COLORMAP_WINDOWS\fP property rather than the
 colormap associated with the top level \fIXnest\fP window.  Since most
 window managers appear to not implement this convention properly as of
 yet, \fIXnest\fP can optionally do direct installation of colormaps