Fix a few typos and clarify a few sentences

1 files changed, 9 insertions, 9 deletions

diff --git a/xc/programs/Xserver/hw/dmx/doc/dmx.sgml b/xc/programs/Xserver/hw/dmx/doc/dmx.sgml
index b5e14d6bf..0337c0af5 100644
--- a/xc/programs/Xserver/hw/dmx/doc/dmx.sgml
+++ b/xc/programs/Xserver/hw/dmx/doc/dmx.sgml
@@ -1080,8 +1080,8 @@ act as a foundation for ongoing work:
 	proxy server and rendering requests are repackaged and sent to
 	each of the back-end servers for display.
 	<item>The multiple screen layout (including support for
-	operlapping screens) will be user configurable in the XF86Config
-	file or through the configuration tool.
+	overlapping screens) will be user configurable via a
+	configuration file or through the configuration tool.
     </itemize>
     <item>Develop graphical configuration tool
     <itemize>
@@ -1116,7 +1116,7 @@ on Xnest and uses the existing Xinerama extension.
 
 <p>Input events can be taken from (1) devices attached to the back-end
 server, (2) core devices attached directly to the Xdmx server, or (3)
-from a "console" window on anther X server.  Events for these devices
+from a ``console'' window on another X server.  Events for these devices
 are gathered, processed and delivered to clients attached to the Xdmx
 server.
 
@@ -1132,7 +1132,7 @@ provided by the vdltodmx utility.
 <p>Originally, the configuration file was going to be a subsection of
 XFree86's XF86Config file, but that was not possible since Xdmx is a
 completely separate X server.  Thus, a separate config file format was
-developed as mentioned above.  In addition, a graphical configuration
+developed.  In addition, a graphical configuration
 tool, xdmxconfig, was developed to allow the user to create and arrange
 the screens in the configuration file.  The -configfile and -config
 command-line options can be used to start Xdmx using a configuration
@@ -1285,9 +1285,9 @@ XRebindKeysym: Test 1 (configuration dependent)
 
 <sect2>Fonts
 
-<p>In phase I, fonts are handled directly by both the front-end and the
+<p>In Phase I, fonts are handled directly by both the front-end and the
 back-end servers, which is required since we must treat each back-end
-server during this phase a a "black box".  What this requires is that
+server during this phase as a ``black box''.  What this requires is that
 <bf/the front- and back-end servers must share the exact same font
 path/.  There are two ways to help make sure that all servers share the
 same font path:
@@ -1309,7 +1309,7 @@ back-end machine.
 
 <p>The -fontpath command line option was added to allow users to
 initialize the font path of the front end server.  This font path is
-propogated to each back-end server when the default font is loaded.  If
+propagated to each back-end server when the default font is loaded.  If
 there are any problems, an error message is printed, which will describe
 the problem and list the current font path.  For more information about
 setting the font path, see the -fontpath option description in the man
@@ -1319,14 +1319,14 @@ page.
 
 <p>Phase I of development was not intended to optimize performance.  Its
 focus was on completely and correctly handling the base X11 protocol in
-the Xdmx server.  However, several insights were gained during phase I,
+the Xdmx server.  However, several insights were gained during Phase I,
 which are listed here for reference during the next phase of
 development.
 
 <enum>
     <item>Calls to XSync() can slow down rendering since it requires a
     complete round trip to and from a back-end server.  This is
-    especially propblematic when communicating over long haul networks.
+    especially problematic when communicating over long haul networks.
     <item>Sending drawing requests to only the screens that they overlap
     should improve performance.
 </enum>