Patch to fix typos in EWHM version 1.0

["David Wheeler" <dwheeler ida org>]

I was very pleased to see the announcement of the window manager spec 1.0,
so I took a look.  I found some typos in it; here's a patch to fix them.
None are critical, but documents with lots of typos are harder to read
and give a poorer impression.  Hopefully these typo fixes can go into
the next revision.

Since I don't think it's fair to change a document without changing
its date & version, the patch changes those values.
Here's a summary of the other things patch does:
* Includes the date in the version text (since some DocBook templates don't
  print the article date).
* Defines an abbreviated name for the spec (EWMH).
* Defines "WM" acronym on first use.
* Inserts a space before _TRANSIENT_FOR.
* Inserts commas in places it's required.
* Inserts English articles (a, the) and does minor grammar clean-ups.
* Fixes spelling (s/iconfying/iconifying/).
* Where it's an RFC 2119 term, it does s/should/SHOULD/ and s/must/MUST/ to
  keep the document consistent.
* There's an illegal character for the "section" character; I fixed it
  to the correct DocBook value "§".



--- wm-spec.sgml.orig	Thu Dec 14 19:18:25 2000
+++ wm-spec.sgml	Thu Dec 14 19:53:18 2000
@@ -2,21 +2,22 @@
 ]>
 <article id="index">
 <artheader>
-<title>Extended Window Manager Hints</title>
-<date>5 November 2000</date>
+<title>Extended Window Manager Hints (EWMH)</title>
+<date>14 December 2000</date>
 </artheader>
 <sect1>
 	<title>Introduction</title>
 	<sect2>
 		<title>Version</title>
 		<para>
-This spec is version 1.0.
+This is version 1.01, dated 14 December 2000, of the
+Extended Window Manager Hints (EWMH) spec.
 		</para>
 	</sect2>
 	<sect2>
 		<title>What is this spec?</title>
 		<para>
-This spec defines interactions between window managers, applications and the
utilities that form part of a desktop environment.  It builds on the ICCCM [2],
which defines wm/client interactions at a lower level.  It was born out of a
need to replace the original Gnome WM specification, although this
specification has been designed to be independent of any one desktop
environment.
+This spec defines interactions between window managers (WMs), applications and
the utilities that form part of a desktop environment.  It builds on the ICCCM
[2], which defines wm/client interactions at a lower level.  It was born out of
a need to replace the original Gnome WM specification, although this
specification has been designed to be independent of any one desktop
environment.
 		</para>
 	</sect2>
 	<sect2>
@@ -38,7 +39,7 @@
 		<para>
 Window Managers and Clients which aim to fulfil this specification MUST adhere
 to the ICCCM on which this specification builds. If this specification
-explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these
+explicitly modifies the ICCCM, Window Managers and Clients MUST fulfil these
 modifications.
 		</para>
 	</sect2>
@@ -82,7 +83,7 @@
 </sect2>
 <sect2>
 <title>Modality</title>
-<para>The Window Manager_TRANSIENT_FOR hint of the ICCCM allows clients to
specify that a
+<para>The Window Manager _TRANSIENT_FOR hint of the ICCCM allows clients to
specify that a
 toplevel window may be closed before the client finishes.  A typical example
 of a transient window is a dialog.  Some dialogs can be open for a long time,
 while the user continues to work in the main window.  Other dialogs have to be
@@ -97,11 +98,11 @@
 <para>The Window Manager may offer to arrange the managed windows on a desktop
that is
 larger than the root window. The screen functions as a viewport on this large
 desktop. Different policies regarding the positioning of the viewport on the
-desktop can be implemented:  The Window Manager may only allow to change the
viewport
+desktop can be implemented:  The Window Manager may only allow changing the
viewport
 position in increments of the screen size (paging) or it may allow arbitrary
 positions (scrolling).</para>
 <para>To fulfill the ICCCM principle that clients should behave the same
-regardless wether a Window Manager is running or not, Window Managers which
+regardless of whether a Window Manager is running or not, Window Managers
which
 implement large desktops must interpret all client-provided geometries with
 respect to the current viewport.</para>
 <sect3 id="largedesksimpl">
@@ -183,7 +184,7 @@
 </sect2>
 <sect2>
 <title>Animated iconification</title>
-<para>Some Window Managers display some form of animation when (de-)iconfying
a window.
+<para>Some Window Managers display some form of animation when (de-)iconifying
a window.
 This may be a line drawing connecting the corners of the window with
 the corners of the icon or the window may be opaquely moved and resized
 on some trajectory joining the window location and the icon location.</para>
@@ -202,7 +203,7 @@
 <para>This spec tries to address the following issues:</para>
 <itemizedlist>
 <listitem><para>Allow clients to influence their initial state with respect
-to maximization, shading, stickyness, desktop.</para></listitem>
+to maximization, shading, stickiness, desktop.</para></listitem>
 <listitem><para>Improve the Window Managers ability to vary window
 decorations by allowing clients to hint the Window Manager about the type
 of their windows.</para></listitem>
@@ -221,7 +222,7 @@
 <para>The Window Manager is supposed to be in charge of window management
 policy, so that there is consistent behaviour on the user's screen no matter
 who wrote the clients.</para>
-<para>The spec offers a lot of external control about Window Manager actions.
+<para>This spec offers a lot of external control over Window Manager actions.
 This is intended mainly to allow pagers, taskbars and similar Window Manager
 UIs to be implemented as separate clients.  "Ordinary" clients shouldn't use
 these except maybe in response to a direct user request (i.e. setting a
@@ -283,10 +284,10 @@
   data.l[0] = new_number_of_desktops
 ]]></programlisting>
 	<para>
-The Window Manager is free to honor or reject this request. If request is
honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops,
_NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root
window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed
accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged.
+The Window Manager is free to honor or reject this request. If the request is
honored, _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops,
_NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root
window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA MUST also be changed
accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged.
 	</para>
 	<para>
-If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the
new range of of available desktops, then this MUST must be set to the last
available desktop from the new set. If number of desktops is shrinking then
clients that are still present on desktops, that are out of the new range, MUST
be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP
MUST be updated.
+If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the
new range of of available desktops, then this MUST be set to the last available
desktop from the new set. If the number of desktops is shrinking, then clients
that are still present on desktops out of the new range MUST be moved to the
very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated.
 	</para>
 	</sect2>
 	<sect2>
@@ -894,14 +895,13 @@
 Applications are free to change their win_gravity setting at any time
 		</para>
 		<para>
-If application changes its gravity then Window manager should adjust the
+If application changes its gravity then Window manager SHOULD adjust the
 reference point, so that client window will not move as the result.
-For example if client's gravity was NorthWestGravity and reference point
-was
+For example, if the client's gravity was NorthWestGravity and its
+reference point was
 at the top-left corner of the frame window, then after change of gravity to
-the SouthEast reference point should be adjusted to point to the
-lower-right
-corner of the frame.
+the SouthEast, its reference point should be adjusted to point to the
+lower-right corner of the frame.
 		</para></listitem>
 		<listitem><para>
 When generating synthetic ConfigureNotify events, the position given
@@ -912,8 +912,8 @@
 XMoveWindow(w,x,y) behaviour depends on the window gravity. Upon receiving a
 request from client application the Window Manager calculates a new reference
 point, based on the client window's own size, border width and gravity. For
given client
-window dimentions (width, height) and border width (bw), the reference point
will be
-placed at:
+window dimentions (width, height) and border width (bw), the reference point
+MUST placed at:
 		</para>
 	  <informaltable>
 	    <tgroup cols="3">
@@ -978,8 +978,9 @@
 	    <!-- one of (tgroup graphic) -->
 	  </informaltable>
 	<para>
-The Window manager will use the reference point as calculated above,
-until next XMoveWindow request. The Window Manager will place frame
decorations
+The Window Manager MUST use the reference point as calculated above,
+until the next XMoveWindow request.
+The Window Manager will place frame decorations
 in the following position, based on the window gravity :
 		</para>
 		<para>
@@ -1047,25 +1048,25 @@
 Implementation Note for Application developers:
 		</para>
 		<para>
-When client window is resized - its reference point does not move.
-So for example if window has SouthEastGravity and it is resized -
-the bottom-right corner of its frame will not move but instead
-top-left corner will be adjusted by the difference in size.
+When a client window is resized, its reference point MUST NOT move.
+For example, if a window has SouthEastGravity and it is resized,
+the bottom-right corner of its frame will not move.
+Instead, its top-left corner will be adjusted by the difference in size.
 		</para></listitem>
 		<listitem><para>
 Implementation Note for WM developers :
 		</para>
 		<para>
-when calculating reference point at the time of initial placement -
-initial window's width should be taken into consideration, as if it
+When calculating a reference point at the time of initial placement, the
+initial window's width SHOULD be taken into consideration, as if it
 was the frame for this window.
 		</para></listitem>
 	</itemizedlist>
 	<para>
-[1] ICCCM Version 2.0, ��4.1.2.3 and ��4.1.5
+[1] ICCCM Version 2.0, &sect;4.1.2.3 and &sect;4.1.5
 	</para>
 	<para>
-[2] ICCCM Version 2.0, ��4.2.3
+[2] ICCCM Version 2.0, &sect;4.2.3
 	</para>
 	</sect2>
 	<sect2>
@@ -1077,7 +1078,8 @@
 	<sect2 id="KILLINGWINDOWS">
 		<title>Killing Hung Processes</title>
 		<para>
-If processes fail to respond to the _NET_WM_PING protocol _NET_WM_PID may be
used in combination with the ICCCM specified WM_CLIENT_MACHINE(STRING) to
attempt to kill a process.
+If processes fail to respond to the _NET_WM_PING protocol,
+_NET_WM_PID may be used in combination with the ICCCM specified
WM_CLIENT_MACHINE(STRING) to attempt to kill a process.
 		</para>
 	</sect2>
 	</Sect1>
@@ -1150,6 +1152,13 @@
 	</sect1>
   <Sect1>
     <title>Change history</title>
+    <sect2>
+		<title>Changes since 1.0</title>
+		<itemizedlist>
+			<listitem><para>Various typos fixed.
+                        </para></listitem>
+		</itemizedlist>
+    </sect2>
     <sect2>
 		<title>Changes since 1.0pre5</title>
 		<itemizedlist>

-- 

--- David A. Wheeler
    dwheeler ida org