+* Underlines appear at the wrong position.
+
+This is caused by fonts having a wrong UNDERLINE_POSITION property.
+An example is the font 7x13 on XFree prior to version 4.1. To
+circumvent this problem, set x-use-underline-position-properties to
+nil in your .emacs.
+
+* Building Emacs with GCC 2.9x fails in the `src' directory.
+
+This may happen if you use a development version of GNU `cpp' from one
+of the GCC snapshots between Oct 2000 and Feb 2001, or from a released
+version of GCC newer than 2.95.2 which was prepared around those
+dates. The preprocessor in those versions expands ".." into ". .",
+which breaks relative file names that reference the parent directory.
+
+The solution is to make sure the preprocessor is run with the
+`-traditional' option. (The `configure' script does that
+automatically.)
+
+Note that this problem does not pertain to the MS-Windows port of
+Emacs, since it doesn't use the preprocessor to generate Makefile's.
+
+* Building the MS-Windows port with Cygwin GCC can fail.
+
+Emacs may not build using recent Cygwin builds of GCC, such as Cygwin
+version 1.1.8, using the default configure settings. It appears to be
+necessary to specify the -mwin32 flag when compiling, and define
+__MSVCRT__, like so:
+
+ configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
+
+* Building the MS-Windows port with Leim fails in the `leim' directory.
+
+The error message might be something like this:
+
+ Converting d:/emacs-21.1/leim/CXTERM-DIC/4Corner.tit to quail-package...
+ Invalid ENCODE: value in TIT dictionary
+ NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code
+ '0xffffffff'
+ Stop.
+
+This can happen if the Leim distribution is unpacked with a program
+which converts the `*.tit' files to DOS-style CR-LF text format. The
+`*.tit' files in the leim/CXTERM-DIC directory require Unix-style line
+endings to compile properly, because Emacs reads them without any code
+or EOL conversions.
+
+The solution is to make sure the program used to unpack Leim does not
+change the files' line endings behind your back. The GNU FTP site has
+in the `/gnu/emacs/windows' directory a program called `djtarnt.exe'
+which can be used to unpack `.tar.gz' and `.zip' archives without
+mangling them.
+
+* JPEG images aren't displayed.
+
+This has been reported when Emacs is built with jpeg-6a library.
+Upgrading to jpeg-6b solves the problem.
+
+* Building `ctags' for MS-Windows with the MinGW port of GCC fails.
+
+This might happen due to a bug in the MinGW header assert.h, which
+defines the `assert' macro with a trailing semi-colon. The following
+patch to assert.h should solve this:
+
+*** include/assert.h.orig Sun Nov 7 02:41:36 1999
+--- include/assert.h Mon Jan 29 11:49:10 2001
+***************
+*** 41,47 ****
+ /*
+ * If not debugging, assert does nothing.
+ */
+! #define assert(x) ((void)0);
+
+ #else /* debugging enabled */
+
+--- 41,47 ----
+ /*
+ * If not debugging, assert does nothing.
+ */
+! #define assert(x) ((void)0)
+
+ #else /* debugging enabled */
+
+
+* When using Xaw3d scroll bars without arrows, the very first mouse
+click in a scroll bar might be ignored by the scroll bar widget. This
+is probably a bug in Xaw3d; when Xaw3d is compiled with arrows, the
+problem disappears.
+
+* Clicking C-mouse-2 in the scroll bar doesn't split the window.
+
+This currently doesn't work with scroll-bar widgets (and we don't know
+a good way of implementing it with widgets). If Emacs is configured
+--without-toolkit-scroll-bars, C-mouse-2 on the scroll bar does work.
+
+* Colors are not available on a tty or in xterm.
+
+Emacs 21 supports colors on character terminals and terminal
+emulators, but this support relies on the terminfo or termcap database
+entry to specify that the display supports color. Emacs looks at the
+"Co" capability for the terminal to find out how many colors are
+supported; it should be non-zero to activate the color support within
+Emacs. (Most color terminals support 8 or 16 colors.) If your system
+uses terminfo, the name of the capability equivalent to "Co" is
+"colors".
+
+In addition to the "Co" capability, Emacs needs the "op" (for
+``original pair'') capability, which tells how to switch the terminal
+back to the default foreground and background colors. Emacs will not
+use colors if this capability is not defined. If your terminal entry
+doesn't provide such a capability, try using the ANSI standard escape
+sequence \E[00m (that is, define a new termcap/terminfo entry and make
+it use your current terminal's entry plus \E[00m for the "op"
+capability).
+
+Finally, the "NC" capability (terminfo name: "ncv") tells Emacs which
+attributes cannot be used with colors. Setting this capability
+incorrectly might have the effect of disabling colors; try setting
+this capability to `0' (zero) and see if that helps.
+
+Emacs uses the database entry for the terminal whose name is the value
+of the environment variable TERM. With `xterm', a common terminal
+entry that supports color is `xterm-color', so setting TERM's value to
+`xterm-color' might activate the color support on an xterm-compatible
+emulator.
+
+Some modes do not use colors unless you turn on the Font-lock mode.
+Some people have long ago set their `~/.emacs' files to turn on
+Font-lock on X only, so they won't see colors on a tty. The
+recommended way of turning on Font-lock is by typing "M-x
+global-font-lock-mode RET" or by customizing the variable
+`global-font-lock-mode'.
+
+* Problems in Emacs built with LessTif.
+
+The problems seem to depend on the version of LessTif and the Motif
+emulation for which it is set up.
+
+Only the Motif 1.2 emulation seems to be stable enough in LessTif.
+Lesstif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD.
+On GNU/Linux systems, lesstif-0.92.6 configured with "./configure
+--enable-build-12 --enable-default-12" is reported to be the most
+successful. The binary GNU/Linux package
+lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with
+menu placement.
+
+On some systems, even with Motif 1.2 emulation, Emacs occasionally
+locks up, grabbing all mouse and keyboard events. We still don't know
+what causes these problems; they are not reproducible by Emacs
+developers.
+
+* Known problems with the MS-Windows port of Emacs 21.1.
+
+Emacs 21.1 built for MS-Windows doesn't support images, the tool bar,
+and tooltips. Support for these will be added in future versions.
+
+There are problems with display if the variable `redisplay-dont-pause'
+is set to nil (w32-win.el sets it to t by default, to avoid these
+problems). The problems include:
+
+ . No redisplay as long as help echo is displayed in the echo area,
+ e.g. if the mouse is on a mouse-sensitive part of the mode line.
+
+ . When the mode line is dragged with the mouse, multiple copies of the
+ mode line are left behind, until the mouse button is released and
+ the next input event occurs.
+
+ . Window contents are not updated when text is selected by dragging
+ the mouse, and the mouse is dragged below the bottom line of the
+ window. When the mouse button is released, the window display is
+ correctly updated.
+
+Again, these problems only occur if `redisplay-dont-pause' is nil.
+
+Emacs can sometimes abort when non-ASCII text, possibly with null
+characters, is copied and pasted into a buffer.
+
+An inactive cursor remains in an active window after the Windows
+Manager driven switch of the focus, until a key is pressed.
+
+Windows 2000 input methods are not recognized by Emacs (as of v21.1).
+These input methods cause the keyboard to send characters encoded in
+the appropriate coding system (e.g., ISO 8859-1 for Latin-1
+characters, ISO 8859-8 for Hebrew characters, etc.). To make this
+work, set the keyboard coding system to the appropriate value after
+you activate the Windows input method. For example, if you activate
+the Hebrew input method, type "C-x RET k iso-8859-8 RET". (Emacs
+ought to recognize the Windows language-change event and set up the
+appropriate keyboard encoding automatically, but it doesn't do that
+yet.)
+
+Multilingual text put into the Windows 2000 clipboard by Windows
+applications cannot be safely pasted into Emacs (as of v21.1). This
+is because Windows 2000 uses Unicode to represent multilingual text,
+but Emacs does not yet support Unicode well enough to decode it. This
+means that Emacs can only interchange non-ASCII text with other
+Windows 2000 programs if the characters are in the system codepage.
+Reportedly, a partial solution is to install the Mule-UCS package and
+set selection-coding-system to utf-16-le-dos.
+
+* The `configure' script doesn't find the jpeg library.
+
+This can happen because the linker by default only looks for shared
+libraries, but jpeg distribution by default doesn't build and doesn't
+install a shared version of the library, `libjpeg.so'. One system
+where this is known to happen is Compaq OSF/1 (`Tru64'), but it
+probably isn't limited to that system.
+
+You can configure the jpeg library with the `--enable-shared' option
+and then rebuild libjpeg. This produces a shared version of libjpeg,
+which you need to install. Finally, rerun the Emacs configure script,
+which should now find the jpeg library. Alternatively, modify the
+generated src/Makefile to link the .a file explicitly.
+
+(If you need the static version of the jpeg library as well, configure
+libjpeg with both `--enable-static' and `--enable-shared' options.)
+
+* Building Emacs over NFS fails with ``Text file busy''.
+
+This was reported to happen when building Emacs on a GNU/Linux system
+(RedHat Linux 6.2) using a build directory automounted from Solaris
+(SunOS 5.6) file server, but it might not be limited to that
+configuration alone. Presumably, the NFS server doesn't commit the
+files' data to disk quickly enough, and the Emacs executable file is
+left ``busy'' for several seconds after Emacs has finished dumping
+itself. This causes the subsequent commands which invoke the dumped
+Emacs excutable to fail with the above message.
+
+In some of these cases, a time skew between the NFS server and the
+machine where Emacs is built is detected and reported by GNU Make
+(it says that some of the files have modification time in the future).
+This might be a symptom of NFS-related problems.
+
+If the NFS server runs on Solaris, apply the Solaris patch 105379-05
+(Sunos 5.6: /kernel/misc/nfssrv patch). If that doesn't work, or if
+you have a different version of the OS or the NFS server, you can
+force the NFS server to use 1KB blocks, which was reported to fix the
+problem albeit at a price of slowing down file I/O. You can force 1KB
+blocks by specifying the "-o rsize=1024,wsize=1024" options to the
+`mount' command, or by adding ",rsize=1024,wsize=1024" to the mount
+options in the appropriate system configuration file, such as
+`/etc/auto.home'.
+
+Alternatively, when Make fails due to this problem, you could wait for
+a few seconds and then invoke Make again. In one particular case,
+waiting for 10 or more seconds between the two Make invocations seemed
+to work around the problem.
+
+* Accented ISO-8859-1 characters are displayed as | or _.
+
+Try other font set sizes (S-mouse-1). If the problem persists with
+other sizes as well, your text is corrupted, probably through software
+that is not 8-bit clean. If the problem goes away with another font
+size, it's probably because some fonts pretend to be ISO-8859-1 fonts
+when they are really ASCII fonts. In particular the schumacher-clean
+fonts have this bug in some versions of X.
+
+To see what glyphs are included in a font, use `xfd', like this:
+
+ xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1
+
+If this shows only ASCII glyphs, the font is indeed the source of the
+problem.
+
+The solution is to remove the corresponding lines from the appropriate
+`fonts.alias' file, then run `mkfontdir' in that directory, and then run
+`xset fp rehash'.
+