Index: trunk/doc/conf/index.html
===================================================================
--- trunk/doc/conf/index.html	(revision 5702)
+++ trunk/doc/conf/index.html	(revision 5703)
@@ -10,7 +10,7 @@
 	<li> ... this led to a variety of configuration formats; using one format not always because it was better suited for the task, but for historical reasons
 	<li> ... this also led to a collection of config files - again not always split by boundaries of settings, but often by arbitrary boundaries of code
 	<li> the old system didn't support lists or arrays well
-	<li> it didn't have a coherent concept of how settings from different <a href="sources.html"> sources </a> would override eachother
+	<li> it didn't have a coherent concept of how settings from different <a href="sources.html"> sources </a> would override each other
 	<li> ... this resulted in the rigid structure that most of the settings could come from only one place (e.g. if it's an user setting, the design won't be able to override it)
 </ul>
 
@@ -17,14 +17,14 @@
 <H2> What the new system offers </H2>
 <ul>
 	<li> unified format: <a href="http://repo.hu/projects/lihata"> lihata </a> ...
-	<li> ... more future proof: generic markup language - easier to extend wihtout having to worry about breaking the syntax
-	<li> ... the configuration is represented in a tree, groupped by the nature of settings
+	<li> ... more future proof: generic markup language - easier to extend without having to worry about breaking the syntax
+	<li> ... the configuration is represented in a tree, grouped by the nature of settings
 	<li> ... there are <a href="lists.html">arrays and lists</a>
 	<li> ... a config file can overwrite a list or <a href="lists.html">prepend/append</a> to it (e.g. design-level config prepending an extra library path keeping system set paths as well)
 	<li> there are different <a href="sources.html"> sources </a> of configuration, e.g. system-wise, user-wise, project-wise, etc.
-	<li> the user has the power to change default config <a href="prio.html">priorty per setting</a>; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
+	<li> the user has the power to change default config <a href="prio.html">priority per setting</a>; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
 	<li> the way settings are stored is flexible and extensible so that a plugin can define their subtree of settings
-	<li> ... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing teir own
+	<li> ... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing their own
 	<li> ... the GUI (gtk's preferences dialog) thus can automatically handle the new settings
 	<li> ... plugins don't have to implement actions to set/toggle/query their settings for the menu system, there are generic config set/toggle/query actions the menu config can use
 	<li> ... plugins also get the multi-source, <a href="prio.html">priority-based config mechanism</a>
Index: trunk/doc/conf/index_user.html
===================================================================
--- trunk/doc/conf/index_user.html	(revision 5702)
+++ trunk/doc/conf/index_user.html	(revision 5703)
@@ -18,7 +18,7 @@
 carry out their tasks.
 <p>
 Config settings are imported from multiple sources: from different files,
-from environment vareiables, from command line arguments, from the .pcb
+from environment variables, from command line arguments, from the .pcb
 files on load. Any source can define any part of the <i>config tree</i>.
 When the configuration is processed, each source is read into a temporary
 tree and then all the temporary trees are merged into the final
@@ -34,7 +34,7 @@
 <a href="sources.html">purpose of the source</a>. The next
 step is following the red arrows in two steps:
 <ul>
-	<li> first merge all the role treesinto a flat list; this determines the value of each setting;
+	<li> first merge all the role trees into a flat list; this determines the value of each setting;
 	<li> then dispatch the values to the right component of the code.
 </ul>
 Some components may change some of the settings run-time. The trivial example
@@ -43,7 +43,7 @@
 to the design role tree directly, from where the new value is again merged
 and dispatched along the red arrows. Changes in the design role are saved
 with the .pcb file (thus the bidirectional black arrow between the source and
-the in-memory tree for the design role). Occassionally the user wants to
+the in-memory tree for the design role). Occasionally the user wants to
 save parts of the setting as a <a href="sources.html"> project setting or
 as an user setting</a> - in this case, along the dashed blue lines, the
 corresponding project or user roles are modified. This again results in updating
@@ -60,7 +60,7 @@
 sets a given item).
 
 <h3> overlaps </h3>
-Each setting in each source has a <a href="prio.html">prioirty.</a> The
+Each setting in each source has a <a href="prio.html">priority.</a> The
 priority can be defined in the source, or if it is not defined, each source
 inherits a fallback default priority. The fallback is designed to provide
 the intuitive order: cli &gt; design &gt; project &gt; user &gt; system.
@@ -79,7 +79,7 @@
 values. They are described in a lihata list item ("li:") in the config
 files and are generally called lists in this document. How lists
 are merged is controlled by the merging <i>policy</i>, which can be
-in each source, just like the prioirty is set. Check out the
+in each source, just like the priority is set. Check out the
 <a href="lists.html">list merging section</a> for more details.
 
 <h3> blind spots </h3>
Index: trunk/doc/conf/prio.html
===================================================================
--- trunk/doc/conf/prio.html	(revision 5702)
+++ trunk/doc/conf/prio.html	(revision 5703)
@@ -15,7 +15,7 @@
 is a tie, role decides: the role closer to the CLI is stronger.
 <p>
 For <a href="lists.html">lists</a> and arrays, priority determines the
-order of merge, which changes the order of itmes in the final list as
+order of merge, which changes the order of items in the final list as
 config roots prepend and append items.
 
 
Index: trunk/doc/conf/scalars.html
===================================================================
--- trunk/doc/conf/scalars.html	(revision 5702)
+++ trunk/doc/conf/scalars.html	(revision 5703)
@@ -26,7 +26,7 @@
 	<tr><td> 2.   <td> apply <i>user</i>   <td> A       <td> "not defined" doesn't mean "empty", so the list is not deleted - no change
 	<tr><td> 3.   <td> apply <i>project</i><td> Q       <td> replace the original output because of the overwrite policy
 </table>
-<p>Example scenario: system default overriden by a project setting.
+<p>Example scenario: system default overridden by a project setting.
 
 <h3> user-forced value </h3>
 Config sources append:
@@ -48,7 +48,7 @@
 <p>Example scenario: user preference enforced: even if the project file would use
 'Q' for the given setting, the user prefers 'E'. This affects runtime
 (the value of the setting after the merge, in other words how pcb-rnd works),
-but does nto change the project configuration. This allows the given user to
+but does not change the project configuration. This allows the given user to
 always use 'E' for the given setting while lets other users working on the
 same project use the value set in the project file.
 
Index: trunk/doc/conf/sources.html
===================================================================
--- trunk/doc/conf/sources.html	(revision 5702)
+++ trunk/doc/conf/sources.html	(revision 5703)
@@ -19,7 +19,7 @@
     <td> 200
     <td> /usr/share/pcb-rnd/pcb-conf.lht
     <td> recommended
-    <td> should hold system and installation specific settigns, e.g. path to the system-wise installed footprint library
+    <td> should hold system and installation specific settings, e.g. path to the system-wise installed footprint library
 
 <tr><td> default.pcb
     <td> 300
@@ -36,12 +36,12 @@
 <tr><td> environment
     <td> 500
     <td> environment variables (TODO)
-    <td> occassional
+    <td> occasional
     <td> inject the same (temporary) settings in multiple pcb-rnd sessions without having to change config files
 
 <tr><td> project
     <td> 600
-    <td> projdect.lht in the project directory
+    <td> project.lht in the project directory
     <td> optional
     <td> local project settings - useful for large projects with multiple design (.pcb) files
 
@@ -54,7 +54,7 @@
 <tr><td> cli
     <td> 800
     <td> command line argument
-    <td> occassional
+    <td> occasional
     <td> inject/change a setting for a single session; useful in batch/automated processing
 </table>
 
@@ -63,7 +63,7 @@
 representation. If a setting is specified in multiple sources, the one
 with the higher priority wins, except for lists where it is also possible
 to prepend/append items. Default priorities are designed to result
-precedence in an intuitive way (e.g. design settigns overwrite user settings).
+precedence in an intuitive way (e.g. design settings overwrite user settings).
 However, <a href="prio.html">priority can be changed</a> per setting, resulting
 in weak settings ("use this value if it was not already set") or strong settings
 ("I always want to use mincut, so I enable it from my user's config with high
Index: trunk/doc/conf/syntax.html
===================================================================
--- trunk/doc/conf/syntax.html	(revision 5702)
+++ trunk/doc/conf/syntax.html	(revision 5703)
@@ -3,11 +3,11 @@
 <H1> The new config system in pcb-rnd </H1>
 <H2> Config file syntax </H2>
 
-The config file sytnax is <a href="http://repo.hu/projects/lihata">lihata</a>.
+The config file syntax is <a href="http://repo.hu/projects/lihata">lihata</a>.
 Most users don't need to understand most of the syntax, just follow the
 patterns seen in the examples. A few thumb of rules:
 <ul>
-	<li> srtuctural nodes usually start with a ha: or li: prefix; which one needs to be used is pretty much tied to the node name; thus casual users don't need to care about what they are for, just remember them as part of the name
+	<li> structural nodes usually start with a ha: or li: prefix; which one needs to be used is pretty much tied to the node name; thus casual users don't need to care about what they are for, just remember them as part of the name
 	<li> non-structural nodes are usually given in the form of name = value; use braces around the value if it contains any non-alphanumeric, non-whitespace character
 	<li> list and array members should better be braced
 	<li> list and array separator should be semicolon (not comma)
@@ -22,7 +22,7 @@
 <p>
 Each config root is a partial description of the
 <a href=index_user.html"> config tree </a> (which is the logical
-confgiuration of all possible settings). Config roots have a policy and
+configuration of all possible settings). Config roots have a policy and
 a <a href="prio.html">priority</a> attached. This is done in the name
 of the config root, which must be of the form of <i>policy-priority</i>,
 e.g. "overwrite-300" or "append-125". The priority part (with the dash)
@@ -31,7 +31,7 @@
 <p>
 Under the config root, a tree of sections (hashes) and setting values
 (text nodes) are built. These structures and values are in 1:1 
-correspondance with <a href="groups.html">the config tree</a>. Excess
+correspondence with <a href="groups.html">the config tree</a>. Excess
 (unknown) keys are considered a warning (except in the plugin/ and
 utils/ subtrees). Missing keys or missing subtrees is normal because a config
 root can be partial.
Index: trunk/doc/conf/tree/editor_selection.html
===================================================================
--- trunk/doc/conf/tree/editor_selection.html	(revision 5702)
+++ trunk/doc/conf/tree/editor_selection.html	(revision 5703)
@@ -3,6 +3,6 @@
 <h2>subtree: editor/selection</h2>
 <table border=1>
 <tr><th>node name <th> type <td> flags <td> description
-<tr><td> disable_negative <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> selection box behaviour: diable the negative-direction selection - any selection box will select only what's fully within the box
+<tr><td> disable_negative <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> selection box behaviour: disable the negative-direction selection - any selection box will select only what's fully within the box
 <tr><td> symmetric_negative <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> selection box behaviour: when set, the selection direction is considered negative only if the box has negative size in the X direction
 </table></body></html>
Index: trunk/doc/conf/tree/rc.html
===================================================================
--- trunk/doc/conf/tree/rc.html	(revision 5702)
+++ trunk/doc/conf/tree/rc.html	(revision 5703)
@@ -6,8 +6,8 @@
 <tr><td> verbose <td><a href="CFN_INTEGER.html"> integer </a><td> 0 <td> <verbose>
 <tr><td> quiet <td><a href="CFN_INTEGER.html"> integer </a><td> 0 <td> print only errors on stderr
 <tr><td> backup_interval <td><a href="CFN_INTEGER.html"> integer </a><td> 0 <td> time between two backups in seconds
-<tr><td> font_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its outout for loading the font; %f is the file name
-<tr><td> file_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its outout for loading a pcb file; %f is the file name, %p is the conf setting rc.file_path
+<tr><td> font_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its output for loading the font; %f is the file name
+<tr><td> file_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its output for loading a pcb file; %f is the file name, %p is the conf setting rc.file_path
 <tr><td> file_path <td><a href="CFN_STRING.html"> string </a><td> 0 <td> <file_path>
 <tr><td> library_shell <td><a href="CFN_STRING.html"> string </a><td> 0 <td> <library_shell>
 <tr><td> library_search_paths <td><a href="CFN_LIST.html"> list </a><td> 0 <td> <library_search_paths>
@@ -20,7 +20,7 @@
 <tr><td> script_filename <td><a href="CFN_STRING.html"> string </a><td> 0 <td> PCB Actions script to execute on startup
 <tr><td> action_string <td><a href="CFN_STRING.html"> string </a><td> 0 <td> PCB Actions string to execute on startup
 <tr><td> rat_path <td><a href="CFN_STRING.html"> string </a><td> 0 <td> <rat_path>
-<tr><td> rat_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its outout for loading a rats; %f is the file name, %p is the rc.rat_path conf setting
+<tr><td> rat_command <td><a href="CFN_STRING.html"> string </a><td> 0 <td> file name template; if not empty, run this command and read its output for loading a rats; %f is the file name, %p is the rc.rat_path conf setting
 <tr><td> preferred_gui <td><a href="CFN_LIST.html"> list </a><td> 0 <td> if set, try GUI HIDs in this order when no GUI is explicitly selected
 <tr><td> have_regex <td><a href="CFN_BOOLEAN.html"> boolean </a><td> 0 <td> whether we have regex compiled in
 </table></body></html>
Index: trunk/doc/developer/hid_remote/proto_high.html
===================================================================
--- trunk/doc/developer/hid_remote/proto_high.html	(revision 5702)
+++ trunk/doc/developer/hid_remote/proto_high.html	(revision 5703)
@@ -65,7 +65,7 @@
 <ul>
 	<li> name: name of the layer (can be empty)
 	<li> id: unique group ID (decimal integer)
-	<li> flags: a list of 3 items: location, purpose and properites. Each item is a list of values (or an empty list).
+	<li> flags: a list of 3 items: location, purpose and properties. Each item is a list of values (or an empty list).
 	<li> group: group ID; layers in the same group are turned on/off together and are considered to be on the same physical layer; -1 means not part of any group
 </ul>
 <p>
@@ -173,7 +173,7 @@
 	<li> y1: 1st corner Y coord (in coord units); y1 &lt;= y2
 	<li> x2: 2nd corner X coord (in coord units)
 	<li> y2: 2nd corner Y coord (in coord units)
-	<li> filled: 1 if the rectangle should be filled; a non-filled rectanlge is a frame of 1 pixel wide lines
+	<li> filled: 1 if the rectangle should be filled; a non-filled rectangle is a frame of 1 pixel wide lines
 </ul>
 
 
Index: trunk/doc/developer/hid_remote/proto_parse.html
===================================================================
--- trunk/doc/developer/hid_remote/proto_parse.html	(revision 5702)
+++ trunk/doc/developer/hid_remote/proto_parse.html	(revision 5703)
@@ -1,6 +1,6 @@
 <html>
 <body>
-Protocol parser state machine of the referece implementation:
+Protocol parser state machine of the reference implementation:
 <img src="proto_parse.svg">
 Legend:
 <ul>
@@ -7,10 +7,10 @@
 	<li> yellow boxes are states
 	<li> blue arrows are optional features for a more tolerant parser
 	<li> round nodes are actions that shall be taken
-	<li> arrow with text: execute aciton or switch state if condition is true
+	<li> arrow with text: execute action or switch state if condition is true
 	<li> arrow without text: do this if no other condition is met
 </ul>
-<h3>Notes on the refernece implementation </H3>
+<h3>Notes on the reference implementation </H3>
 The reference implementation builds a <b>tree of nodes</b> for the arguments.
 Each node is either a list or a text. A node has a pointer to its parent, its
 first child and its next sibling. While parsing list-of-lists, the parser
@@ -35,4 +35,4 @@
 </ul>
 
 </body>
-</html>
\ No newline at end of file
+</html>
Index: trunk/doc/developer/indent.html
===================================================================
--- trunk/doc/developer/indent.html	(revision 5702)
+++ trunk/doc/developer/indent.html	(revision 5703)
@@ -10,6 +10,6 @@
 </pre>
 <p>
 Contributors are kindly asked to follow this style or run the above commandline
-on their code before sending a patch or commiting to svn.
+on their code before sending a patch or committing to svn.
 </body>
 </html>
Index: trunk/doc/developer/mods3/index.html
===================================================================
--- trunk/doc/developer/mods3/index.html	(revision 5702)
+++ trunk/doc/developer/mods3/index.html	(revision 5703)
@@ -12,7 +12,7 @@
 HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
 gpmi module as a separate plugin.
 <p>
-In version 1.0.8 to 1.1.0 a cosiderable chunk of core code has been moved into
+In version 1.0.8 to 1.1.0 a considerable chunk of core code has been moved into
 <i>core plugins</i>. A <i>core plugin</i> is just a plugin that is
 maintained together with the core, in the same repository, still the code is
 somewhat detached from the core. More importantly, the user can choose, for
Index: trunk/doc/developer/mods3/pre.html
===================================================================
--- trunk/doc/developer/mods3/pre.html	(revision 5702)
+++ trunk/doc/developer/mods3/pre.html	(revision 5703)
@@ -12,7 +12,7 @@
 HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
 gpmi module as a separate plugin.
 <p>
-In version 1.0.8 to 1.1.0 a cosiderable chunk of core code has been moved into
+In version 1.0.8 to 1.1.0 a considerable chunk of core code has been moved into
 <i>core plugins</i>. A <i>core plugin</i> is just a plugin that is
 maintained together with the core, in the same repository, still the code is
 somewhat detached from the core. More importantly, the user can choose, for
Index: trunk/doc/devlog/20150821a_parametric_requirements.html
===================================================================
--- trunk/doc/devlog/20150821a_parametric_requirements.html	(revision 5702)
+++ trunk/doc/devlog/20150821a_parametric_requirements.html	(revision 5703)
@@ -17,7 +17,7 @@
 <li> dimensions and other properties can be calculated from the base 
 properties with reasonable formulas and conditional code; e.g. sot* is not 
 a good candidate for generation, as sot23 or sot89 can not be generated 
-from some common anestor by varying one or two parameters, but would need 
+from some common ancestor by varying one or two parameters, but would need 
 a large table that translates package name to a pattern - easier to keep 
 those in static footprint files
 
Index: trunk/doc/devlog/20150830a_fork_faq.html
===================================================================
--- trunk/doc/devlog/20150830a_fork_faq.html	(revision 5702)
+++ trunk/doc/devlog/20150830a_fork_faq.html	(revision 5703)
@@ -122,7 +122,7 @@
 <H4> 2.7. But that's extra effort and makes life harder! </H4>
 Yes and no. It's certainly harder to design and carry out a big
 reorganization in small steps. This is an extra cost. However, the
-benefits outweight this: everyone working in the same repo,
+benefits outweigh this: everyone working in the same repo,
 other developers see and comment what you are working on, if done right,
 merging is nearly never needed and conflicts are as rare as bugfree
 release of a multi-million line proprietary software.
@@ -173,7 +173,7 @@
 No, we don't. I prefer human readable text formats. No, converters won't
 solve that. No, I don't care if python has support for loading SQL files.
 <p>
-<b>Update (Aug 2016):</b> the file format is a replacable plugin now;
+<b>Update (Aug 2016):</b> the file format is a replaceable plugin now;
 it's even possible to have multiple alternative formats active in the same
 time. It's up to you to implement your format in a plugin.
 
Index: trunk/doc/devlog/20150830b_back_ann.html
===================================================================
--- trunk/doc/devlog/20150830b_back_ann.html	(revision 5702)
+++ trunk/doc/devlog/20150830b_back_ann.html	(revision 5703)
@@ -95,7 +95,7 @@
 the table adding B1 to n2, so that rule is kept.
 <p>
 <b>net_info</b> is used to describe the <b>original</b> members of a net, in
-the state they were before any change on the netlist occured.
+the state they were before any change on the netlist occurred.
 
 <H3> Support in pcb-rnd: GUI </H3>
 A trivial idea is to extend the netlist window so that pins can be moved in
@@ -218,7 +218,7 @@
 
 <H3> Amendment 1: other parameters (1st sep)</H3>
 I originally forgot to mention my other intentions in the above document:
-back annotate non-netlist properites. It probably happened because netlist
+back annotate non-netlist properties. It probably happened because netlist
 related stuff are the hardest to solve.
 <p>
 There are other parameters that sometimes change during routing. A common case
@@ -268,7 +268,7 @@
 del_conn netname1 U1-1
 add_conn netname2 U1-1
 	</pre>
-	<li> the user may need to load the netlist patch in ghscem
+	<li> the user may need to load the netlist patch in gschem
 	<li> In gschem there would be an indication that highlights any U1-1 pin or
 	U1 symbol that makes a connection to netname 1, graphically or using
 	attributes. When asked, gschem UI would also tell the user that U1-1 is
@@ -285,7 +285,7 @@
 <ul>
 	<li> The user creates the schematics and imports it in pcb; originally
 	     U1 has an attribute footprint=DIP(8).
-	<li> during the layout the user figures using the footpritn SO(8) is
+	<li> during the layout the user figures using the footprint SO(8) is
 	     more appropriate. He does the change in pcb-rnd.
 	<li> pcb-rnd emits the following netlist patch for this:
 	<pre>
@@ -293,12 +293,12 @@
 	</pre>
 	<p>
 	(or it could be a del_attrib and add_attrib pair, like with connections)
-	<li> the user may need to load the netlist patch in ghscem
+	<li> the user may need to load the netlist patch in gschem
 	<li> In gschem there would be an indication that highlights any U1 instances
 	     that has footprint=DIP(8)
 	<li> The user would find this indication and would resolve the situation
 	     by whatever changes he finds appropriate (e.g. change the attribute)
 	<li> gschem would rerun the patch commands and would figure the change is
-	     no longer requred and would remove the indication
+	     no longer required and would remove the indication
 </ul>
 
Index: trunk/doc/devlog/20151028_glib.html
===================================================================
--- trunk/doc/devlog/20151028_glib.html	(revision 5702)
+++ trunk/doc/devlog/20151028_glib.html	(revision 5703)
@@ -16,7 +16,7 @@
 functions for performance, maybe that's why.
 <p>
 So I tried to reproduce the situation in a hello-world like program and 
-tried all combinaton of --std, -DNDEBUG, -rdynamic and all build flags 
+tried all combination of --std, -DNDEBUG, -rdynamic and all build flags 
 used in pcb-rnd for the genht lib and the test program, but all combination 
 worked. It looked like it broke only in pcb-rnd.
 <p>
@@ -33,7 +33,7 @@
 <p>
 The morale of the story is... Well, I have multiple conclusions.
 <ul>
-<li> glib is not a lib that tries to solve something, it is a prorgamming 
+<li> glib is not a lib that tries to solve something, it is a proggamming 
 environment that tries to supersede C.
 
 <li> As such, it feels free to mess with the environment, redefine C 
@@ -54,7 +54,7 @@
 </ul>
 
 <p>
-In a nuthsell this is why I don't believe in glib-like solve-all megalibs. I 
+In a nutshell this is why I don't believe in glib-like solve-all megalibs. I 
 don't say size alone determines this, but size is a good indication of 
 potential problems.
 <p>
@@ -62,4 +62,4 @@
 will bring a lot of unneeded bloat that likely to break things.
 
 </body>
-</html>
\ No newline at end of file
+</html>
Index: trunk/doc/devlog/20160101_cschem.html
===================================================================
--- trunk/doc/devlog/20160101_cschem.html	(revision 5702)
+++ trunk/doc/devlog/20160101_cschem.html	(revision 5703)
@@ -47,7 +47,7 @@
 	<li> 3. project management
 		<ul>
 			<li> 3.1. automatic tests wherever possible, as early as possible
-			<li> 3.2. * VCS: simple, centralized svn with straight linear developement, actively trying to avoid branching
+			<li> 3.2. * VCS: simple, centralized svn with straight linear development, actively trying to avoid branching
 			<li> 3.3. * near-zero-administration releases with svn commits 
 			<li> 3.4. * users should be able to submit bug reports anonymously, without having to register, without having to run javascript, java applet, flash, etc.
 		</ul>
Index: trunk/doc/devlog/20160409/header
===================================================================
--- trunk/doc/devlog/20160409/header	(revision 5702)
+++ trunk/doc/devlog/20160409/header	(revision 5703)
@@ -1,7 +1,7 @@
 1. Do you use the lesstif HID?
 2. If there were different menu resources files distributed with PCB, would you try them?
 3. Do you customize your menu resource file?
-4. If you do not costumize your menu resource file, it's because
+4. If you do not customize your menu resource file, it's because
 5. Do you miss multi-key sequences from the GTK hid?
 6. If the GTK hid supported multi-key sequences, would that change any of your previous answers?
 7. Vendor (drill) mapping also uses a resource file.
Index: trunk/doc/devlog/20160409/header.csv
===================================================================
--- trunk/doc/devlog/20160409/header.csv	(revision 5702)
+++ trunk/doc/devlog/20160409/header.csv	(revision 5703)
@@ -1 +1 @@
-1. Do you use the lesstif HID?,2. If there were different menu resources files distributed with PCB, would you try them?,3. Do you customize your menu resource file?,4. If you do not costumize your menu resource file, it's because,5. Do you miss multi-key sequences from the GTK hid?,6. If the GTK hid supported multi-key sequences, would that change any of your previous answers?,7. Vendor (drill) mapping also uses a resource file.,
\ No newline at end of file
+1. Do you use the lesstif HID?,2. If there were different menu resources files distributed with PCB, would you try them?,3. Do you customize your menu resource file?,4. If you do not customize your menu resource file, it's because,5. Do you miss multi-key sequences from the GTK hid?,6. If the GTK hid supported multi-key sequences, would that change any of your previous answers?,7. Vendor (drill) mapping also uses a resource file.,
Index: trunk/doc/devlog/20160409/poll.html
===================================================================
--- trunk/doc/devlog/20160409/poll.html	(revision 5702)
+++ trunk/doc/devlog/20160409/poll.html	(revision 5703)
@@ -3,7 +3,7 @@
 <th>1. Do you use the lesstif HID?
 <th>2. If there were different menu resources files distributed with PCB, would you try them?
 <th>3. Do you customize your menu resource file?
-<th>4. If you do not costumize your menu resource file, it's because
+<th>4. If you do not customize your menu resource file, it's because
 <th>5. Do you miss multi-key sequences from the GTK hid?
 <th>6. If the GTK hid supported multi-key sequences, would that change any of your previous answers?
 <th>7. Vendor (drill) mapping also uses a resource file.
@@ -48,11 +48,11 @@
 b. yes, sometimes, rarely (e.g. I once had to do something repeatedly and 
 added a key binding for that)
 c. never, I know where I'd perform the changes if I ever needed 
-them but defalts are good enough for now
+them but defaults are good enough for now
 d. never, I don't know what a menu resource file is
 
 
-4. If you do not costumize your menu resource file, it's because (select 
+4. If you do not customize your menu resource file, it's because (select 
 zero or more):
 a. I don't need to
 b. the file is too long
@@ -61,7 +61,7 @@
 e. I don't like the idea of editing text config files, I want a GUI for 
 this
 f. I don't want to diverge from the default settings (e.g. because of 
-potetial hassle at a later upgrade)
+potential hassle at a later upgrade)
 
 
 5. Do you miss multi-key sequences from the GTK hid? (select one)
Index: trunk/doc/devlog/20160826_virtusers.html
===================================================================
--- trunk/doc/devlog/20160826_virtusers.html	(revision 5702)
+++ trunk/doc/devlog/20160826_virtusers.html	(revision 5703)
@@ -16,7 +16,7 @@
 just different defaults. I felt other users may find the new features useful,
 so I had <i>put</i> it on offer: advertised the repository. I thought users
 would download and try the software. Judging from the feedback, they didn't. I
-didn't mind, becuase I was working on features I needed, to get pcb-rnd do what
+didn't mind, because I was working on features I needed, to get pcb-rnd do what
 I wanted: I was my own target audience and anyone else trying pcb-rnd could
 only be a side effect. Until when I ran out of features because it already
 had everything I needed.
@@ -28,7 +28,7 @@
 <p>
 This was when I realized what was really happening: I was <i>offering</i>
 features for <i>virtual</i> users, addressing my communication to the wide
-auidence. Noone really felt it was for him. Even if he was complaining about
+audience. Noone really felt it was for him. Even if he was complaining about
 a missing feature in pcb and a few days later I announced the fix in pcb-rnd, it
 was not specifically for him, but for the Greater Good.
 <p>
@@ -43,7 +43,7 @@
 and many of them got hooked up. They all became productive, active members
 of the pcb-rnd community.
 <p>
-Learning from this experiece, the new strategy of pcb-rnd is as follows:
+Learning from this experience, the new strategy of pcb-rnd is as follows:
 <ul>
 	<li> pull instead of offer: do not hope a new feature would attract users,
 	     rather arrange active users who then pull the project with their
@@ -52,8 +52,8 @@
 	     by actual, existing, active users; rather invest that time in fulfilling
 	     the needs of already existing users
 	<li> reaching 100 users with an average of 0.1% activity will result in
-	     0 active useres whereas reaching only 10 users with 30% activity
-	     will result in 3 active users; thus a small active communit around
+	     0 active users whereas reaching only 10 users with 30% activity
+	     will result in 3 active users; thus a small active community around
 	     pcb-rnd is more efficient than the much larger geda community;
 	<li> users really appreciate fast response on bugreports and feature requests.
 	     Instead of trying to impress virtual users, rather keep already interested
Index: trunk/doc/features/index.html
===================================================================
--- trunk/doc/features/index.html	(revision 5702)
+++ trunk/doc/features/index.html	(revision 5703)
@@ -43,7 +43,7 @@
 <tr><td bgcolor=#ccccff><a href="../developer/mods3/">[mods]</a>   <td bgcolor=#ddddff> modularize the code to reduce core size - for comparison
 <tr><td bgcolor=#ccccff><a href="unglib.html">[unglib]</a>         <td bgcolor=#ddddff> remove glib dependency from core
 <tr><td bgcolor=#ccccff><a href="io.html">[io_*]</a>               <td bgcolor=#ddddff> .pcb and .fp file format plugins
-<tr><td bgcolor=#ccccff><a href="dynstyle.html">[dynstyle]</a>     <td bgcolor=#ddddff> dynamic routuing style: sypport more than 4 of them - with no limit
+<tr><td bgcolor=#ccccff><a href="dynstyle.html">[dynstyle]</a>     <td bgcolor=#ddddff> dynamic routing style: support more than 4 of them - with no limit
 <tr><td bgcolor=#ccccff><a href="../conf/index.html">[conf]</a>    <td bgcolor=#ddddff> new, unified, config file system
 <tr><td bgcolor=#ccccff><a href="propedit.html">[propedit]</a>     <td bgcolor=#ddddff> property/attribute editor (gtk)
 <tr><td bgcolor=#ccccff><a href="oldplugins.html">[oldplugins]</a> <td bgcolor=#ddddff> import old PCB plugins
Index: trunk/doc/features/mincut.html
===================================================================
--- trunk/doc/features/mincut.html	(revision 5702)
+++ trunk/doc/features/mincut.html	(revision 5703)
@@ -52,7 +52,7 @@
 to the place where the problem really is - much closer than the pins/pads.
 <p>
 Since mincut can be expensive on large boards, the feature can be enabled
-per board (a new PCB flag) and can be disbaled globally (--enable-mincut 0
+per board (a new PCB flag) and can be disabled globally (--enable-mincut 0
 when starting PCB).
 
 <h2> save/load and compatibility </h2>
Index: trunk/doc/features/negselect.html
===================================================================
--- trunk/doc/features/negselect.html	(revision 5702)
+++ trunk/doc/features/negselect.html	(revision 5703)
@@ -34,7 +34,7 @@
 The feature can be disabled using the editor/selection/disable_negative conf
 setting.
 <p>
-It's possible to limit the feature so that only hirozintal-negative is
+It's possible to limit the feature so that only horizontal-negative is
 considered negative size (i.e. only right-to-left dragging), using the
 editor/selection/symmetric_negative conf setting.
 
Index: trunk/doc/features/oldplugins.html
===================================================================
--- trunk/doc/features/oldplugins.html	(revision 5702)
+++ trunk/doc/features/oldplugins.html	(revision 5703)
@@ -36,7 +36,7 @@
 	<li> smaprtdisperse
 </ul>
 <p>
-The import/export plugins improted over the default set of the last official
+The import/export plugins imported over the default set of the last official
 mainline release:
 <ul>
 	<li> import_dsn - specctra importer - compiles, parser needs a full rewrite, it tries to read an s-expression line by line with fgets()
Index: trunk/doc/features/pcb-fp.html
===================================================================
--- trunk/doc/features/pcb-fp.html	(revision 5702)
+++ trunk/doc/features/pcb-fp.html	(revision 5703)
@@ -33,7 +33,7 @@
 </ul>
 
 <h3> Example </h3>
-Intaractive parametric footprint selection in pcb-rnd:
+Interactive parametric footprint selection in pcb-rnd:
 <p>
 <img src="pcb-fp.png">
 <p>
Index: trunk/doc/features/pcblib.html
===================================================================
--- trunk/doc/features/pcblib.html	(revision 5702)
+++ trunk/doc/features/pcblib.html	(revision 5703)
@@ -22,7 +22,7 @@
 <table border=0>
 <tr><td valign=top>
 The footprint library shipped with mainline pcb is cluttered with
-special puprose parts. I believe PCB encourages the user from
+special purpose parts. I believe PCB encourages the user from
 an early stage to build his own library. Thus the purpose of
 the library shipped with PCB should be
 to provide a minimal collection of real essential footprints ...
@@ -40,13 +40,13 @@
 an online interface to the parametric footprint generators. </a>
 
 <h2> Design decisions </h2>
-Parts are sorted only in a few directories: smd, tru-hole, connector and
-parametric. I believe there are so many orthogonal properties of footpritns
-that there's no obvious hierarchy. Also, pcblib contains much fewer footpritns
+Parts are sorted only in a few directories: smd, thru-hole, connector and
+parametric. I believe there are so many orthogonal properties of footprints
+that there's no obvious hierarchy. Also, pcblib contains much fewer footprints
 than newlib so it should be still easy to navigate.
 <p>
 Parametric footprints are in a separate directory for now, even tho they
-would fit under smd, tru-hole or connector. The reason is purely historical
+would fit under smd, thru-hole or connector. The reason is purely historical
 and the layout may change in the future.
 
 <h2> Example </h2>
@@ -55,9 +55,9 @@
 subdirectory!
 
 <h2> [fp_fs] </h2>
-As of vesion 1.0.10, the footprint list/search/load of footprints is a plugin.
+As of version 1.0.10, the footprint list/search/load of footprints is a plugin.
 The original code that handles local file system footprint libraries (e.g.
-pcblib or newlib) is now a plugin. Altnerative plugins can be provided that work
+pcblib or newlib) is now a plugin. Alternative plugins can be provided that work
 from databases or <a href="fp_wget.html"> from the web</a>. In extreme
 situations the file system based footprint plugin can even be disabled.
 
Index: trunk/doc/features/query.html
===================================================================
--- trunk/doc/features/query.html	(revision 5702)
+++ trunk/doc/features/query.html	(revision 5703)
@@ -20,7 +20,7 @@
 
 <h1> pcb-rnd - [query] </h1>
 Pcb-rnd features a flexible query language that can list (or select or find, etc.)
-objects mathcing an expression. The language handles different data types,
+objects matching an expression. The language handles different data types,
 including lists, provides means to iterate over objects and lists, supports
 the common logical and arithmetic operators.
 <p>
Index: trunk/doc/features/res.html
===================================================================
--- trunk/doc/features/res.html	(revision 5702)
+++ trunk/doc/features/res.html	(revision 5703)
@@ -22,13 +22,13 @@
 
 PCB used to have an own file format for describing resources (menu structure
 and hotkey bindings, vendor drill mapping). The resource format was generic
-enough to describe these things, but the syntax was somewhat wierd: mixed
+enough to describe these things, but the syntax was somewhat weird: mixed
 positional and named fields. More precisely, composite nodes could contain
 named and anonymous subnodes, and the meaning of anonymous subnodes depended
 on their position in the anon-subnode-list.
 <p>
 The code that dealt with the in-memory representation of the resource tree
-was wierd and big chunks duplicated in the HIDs and vendor drill module. It
+was weird and big chunks duplicated in the HIDs and vendor drill module. It
 was also hard to parse a resource file with external tools.
 <p>
 Since version 1.0.10, pcb-rnd replaces resource files with 
@@ -45,7 +45,7 @@
 
 <h2> menu files </h2>
 There are pcb-menu-gtk.lht and pcb-menu-lesstif.lht. They are in trunk/src
-in the source tree and are instaslled in the SHAREDIR. Currently each GUI
+in the source tree and are installed in the SHAREDIR. Currently each GUI
 HID (lesstif, gtk) loads the corresponding menu file.
 
 <h2> menu resource lihata structure </h2>
@@ -56,7 +56,7 @@
 	<li> <i>li:main_menu</i> for describing the main menu
 	<li> <i>li:popups</i> for describing the popup menus
 </ul>
-All children are optional, but recommended. Thus the file stucture, zoomed
+All children are optional, but recommended. Thus the file structure, zoomed
 out, is:
 <pre>
 ha:{
@@ -100,7 +100,7 @@
 Special menu items are text nodes instead of hashes; they are:
 <ul>
 	<li> starting with @, are dynamic, auto-generated items (e.g. layers; might be HID-dependent)
-	<li> a singel dash: separator
+	<li> a single dash: separator
 </ul>
 <p>
 A key description is a text in the form of:
Index: trunk/doc/features/routings.html
===================================================================
--- trunk/doc/features/routings.html	(revision 5702)
+++ trunk/doc/features/routings.html	(revision 5703)
@@ -23,7 +23,7 @@
 <h2> Number of styles </h2>
 In the original code there are a compile-time fixed number (4) of routing
 styles. This is often not enough for more complex designs. While in theory
-this limit can be raised, the resulting .pcb files will be incomatible with
+this limit can be raised, the resulting .pcb files will be incompatible with
 pcb compilations using a different number of styles.
 <p>
 Pcb-rnd uses a dynamic vector for storing styles and allows any number
@@ -42,7 +42,7 @@
 <p>
 In mainline PCB the implicit (or pen) style is hidden. As long as it always
 matches one of the existing styles, the user doesn't even know about it.
-However, if there are objects that do not comform to any of the existing
+However, if there are objects that do not conform to any of the existing
 styles, it is possible to bump into this. For example:
 <ul>
 	<li> draw a line using one of the existing styles
Index: trunk/doc/index.html
===================================================================
--- trunk/doc/index.html	(revision 5702)
+++ trunk/doc/index.html	(revision 5703)
@@ -53,7 +53,7 @@
 		<br> <a href="http://www.repo.hu/cgi-bin/pcb-rnd-people.cgi?cmd=timeline"> predictable development cycles </a>
 		<br> compatible with <b>KiCad</b> and <b>gEDA/PCB</b>
 
-	<tr><th align=right valign=top bgcolor=#ccccff> Suported platforms <td bgcolor=#ddddff>
+	<tr><th align=right valign=top bgcolor=#ccccff> Supported platforms <td bgcolor=#ddddff>
 		     Linux desktop (various distributions, from source)
 		<br> <a href="mac.txt"> Mac OS X </a>
 		<br> <a href="https://aur.archlinux.org/packages/pcb-rnd-svn/"> Arch Linux (user package) </a>
@@ -90,7 +90,7 @@
 	<table border=0 cellspacing=10 cellpadding=0  bgcolor=#ccffcc>
 	<tr><td>
 	<font size=+2><b>R</b>esponse <b>N</b>ot <b>D</b>elayed</font>
-	<td> Bugrepots, user requests and patches submitted are answered ASAP. There are no patches bitrotting for months. There are no forgotten bugreports.
+	<td> Bugreports, user requests and patches submitted are answered ASAP. There are no patches bitrotting for months. There are no forgotten bugreports.
 	</table>
 
 	<p>
Index: trunk/doc/irc.html
===================================================================
--- trunk/doc/irc.html	(revision 5702)
+++ trunk/doc/irc.html	(revision 5703)
@@ -31,7 +31,7 @@
 <p>
 Using the web client: you may change your nickname; there's no password
 or registration or channel key or ssl of any form. Your real IP won't be
-shown on the IRC network (check kiwiirc's page about thier privacy
+shown on the IRC network (check kiwiirc's page about their privacy
 policy).
 <p>
 Connecting with the web client may take some time, give it a minute.
Index: trunk/doc/man/pcb-rnd.1
===================================================================
--- trunk/doc/man/pcb-rnd.1	(revision 5702)
+++ trunk/doc/man/pcb-rnd.1	(revision 5703)
@@ -19,7 +19,7 @@
 .TH pcb-rnd 1 2016-10-29 "" "pcb-rnd manual"
 .SH NAME
 pcb-rnd - Printed Circuit Board editor
-.SH SYNPOSIS
+.SH SYNOPSIS
 .nf
 .sp
 \fBpcb-rnd [\fIoptions\fB] [\fIinputfile\fB]
@@ -38,7 +38,7 @@
 .TP
 
 .B --gui \fIhid\fR 
-Use the \fIhid\fR plugin for the "gui" frontend. Common choices are "gtk" or "lesstif" for graphical user intrfaces and "batch" for a headless command-line interface (or automated batch processing). 
+Use the \fIhid\fR plugin for the "gui" frontend. Common choices are "gtk" or "lesstif" for graphical user interfaces and "batch" for a headless command-line interface (or automated batch processing). 
 .TP
 
 .B -c \fIpath=val\fR 
Index: trunk/doc/man/pcb-rnd.1.html
===================================================================
--- trunk/doc/man/pcb-rnd.1.html	(revision 5702)
+++ trunk/doc/man/pcb-rnd.1.html	(revision 5703)
@@ -33,7 +33,7 @@
 pcb-rnd - Printed Circuit Board editor
 </blockquote>
 
-<H3>SYNPOSIS</H3>
+<H3>SYNOPSIS</H3>
 <blockquote>
 <P>
 <tt><B>pcb-rnd</B> [<I>options</I>] [<I>inputfile</I>]</tt>
@@ -60,7 +60,7 @@
 	<TR>
 
 		<TD> --gui <I>hid</I> 
-		<TD> Use the <I>hid</I> plugin for the "gui" frontend. Common choices are "gtk" or "lesstif" for graphical user intrfaces and "batch" for a headless command-line interface (or automated batch processing). 
+		<TD> Use the <I>hid</I> plugin for the "gui" frontend. Common choices are "gtk" or "lesstif" for graphical user interfaces and "batch" for a headless command-line interface (or automated batch processing). 
 	<TR>
 
 		<TD> -c <I>path=val</I> 
Index: trunk/doc/man/pcb-rnd.1.mml
===================================================================
--- trunk/doc/man/pcb-rnd.1.mml	(revision 5702)
+++ trunk/doc/man/pcb-rnd.1.mml	(revision 5703)
@@ -24,7 +24,7 @@
 	<item>
 		<key> --gui <arg>hid</arg> </key>
 		<value> Use the <arg>hid</arg> plugin for the "gui" frontend. Common
-		        choices are "gtk" or "lesstif" for graphical user intrfaces
+		        choices are "gtk" or "lesstif" for graphical user interfaces
 		        and "batch" for a headless command-line interface (or automated
 		        batch processing). </value>
 	</item>
Index: trunk/doc/myfeature.html
===================================================================
--- trunk/doc/myfeature.html	(revision 5702)
+++ trunk/doc/myfeature.html	(revision 5703)
@@ -26,9 +26,9 @@
 <H3> 1. If you are a programmer with free time to spend </H3>
 Read the <a href="contrib.html"> contribution howto</a> and join the project.
 You are welcome to work only on the feature you are interested in. You get
-all the support (e.g. for understending the API, to get a blank plugin
+all the support (e.g. for understanding the API, to get a blank plugin
 set up so you need to fill in only the feature-specific parts, etc.). Success
-rate shoudl be near to 100%.
+rate should be near to 100%.
 
 <H3> 2. If you are not a programmer and have free time </H3>
 You can join and work on things you don't need that much, but others do.
@@ -41,7 +41,7 @@
 (see the <a href="contrib.html"> contribution howto</a> page). Since
 you don't need to cover all costs and the hourly rates are much lower
 on a pet project, and your feature may be simpler than it looks, and
-someone who already knows the code also saves the learning cureve, it may
+someone who already knows the code also saves the learning curve, it may
 all be cheaper than you think. The success rate should be close to 100%.
 <p>
 However, this is a last resort solution, the above ones are clearly preferred.
@@ -55,8 +55,8 @@
 <p>
 Because of 100% passivity of the geda community, I decided not to spend more
 time on community-related tasks. The poll is there, you can use it,
-but you will have to orgnaize at least 5 active, capable users who are
-commited enough to spend significant time on testing/supporting development.
+but you will have to organize at least 5 active, capable users who are
+committed enough to spend significant time on testing/supporting development.
 I will consider implementing your feature only if you can bring and keep
 those people motivated and active.
 
Index: trunk/doc/user/02_model/index.html
===================================================================
--- trunk/doc/user/02_model/index.html	(revision 5702)
+++ trunk/doc/user/02_model/index.html	(revision 5703)
@@ -20,7 +20,7 @@
 <b>Board size</b> is given as a width and a height. For rectangular boards
 this can be the real board size, but more commonly it is used to simply
 determine the on-screen drawing area and the final board dimensions are
-specified using the outline layer. If the board is not rectagnular, the
+specified using the outline layer. If the board is not rectangular, the
 contour must be specified on the outline layer and the board size must be
 large enough that the outline fits in it.
 <p>
@@ -117,8 +117,8 @@
 <p>
 <img src="obj_line.png">
 <p>
-A <i>clearance</i> is the gap between a line and the sorrunding polygon
-in the same layer group. The gap is made only if the sorrunding polygon has
+A <i>clearance</i> is the gap between a line and the sorrounding polygon
+in the same layer group. The gap is made only if the sorrounding polygon has
 the "clearpoly" flag set and the line has the "clearline" flag set. If either
 of these flags is not set, no gap is made - or in pcb-rnd terminology,
 the line is joined to the polygon.
@@ -150,9 +150,9 @@
 <h4> 2.4.3. Polygon objects </h4>
 <p>
 Polygons are solid, filled copper areas with optional holes in them. Polygon
-contour consits of lines - when they look curvy, it's really high resolution
+contour consists of lines - when they look curvy, it's really high resolution
 line approximation. There are two type of holes in a polygon: <i>explicit</i>,
-user drawn holes and <i>clerance</i> cutouts. User drawn holes are "negative"
+user drawn holes and <i>clearance</i> cutouts. User drawn holes are "negative"
 polygons drawn manually. To keep polygons simple, if an user drawn hole
 touches the contour of a polygon, the hole is removed and the contour is
 modified; if two holes touch, they are merged into one hole.
@@ -170,7 +170,7 @@
 if there are multiple such polygons overlapping under the objects (on
 the same layer group), all such polygons get the clearance cutout.
 <p>
-If a polgyon is cut into multiple islands, the behaviour depends on the
+If a polygyn is cut into multiple islands, the behaviour depends on the
 "fullpoly" flag of the polygon. If it is not set (default), only the largest
 island is kept, else all islands are kept. In the "fullpoly" mode islands
 will have no galvanic connection (unless the user adds vias and connect them
@@ -212,11 +212,11 @@
 ring around the hole on each layer have the same sizes.
 <p>
 A copper ring also has a per layer property whether or how it connects to
-the sorrunding polygon on the given layer; this is called the thermal style
+the sorrounding polygon on the given layer; this is called the thermal style
 of the via. The following options are available:
 <table border=1>
 	<tr><th>thermal style <th> appearance
-	<tr><td>no connecton <td> <img src=TODO>
+	<tr><td>no connection <td> <img src=TODO>
 	<tr><td>solid        <td> <img src=TODO>
 	<tr><td>round x 90   <td> <img src=TODO>
 	<tr><td>round x 45   <td> <img src=TODO>
@@ -241,7 +241,7 @@
 board or loaded into a paste buffer.
 
 <p>
-In the footprint form the construct is small and flexible. Ot describes
+In the footprint form the construct is small and flexible. It describes
 all the physical parts, like pins, pads, silk lines. In the same time a
 footprint leaves many details blank, e.g. it doesn't specify exact layers,
 it doesn't a have font and the refdes is random.
@@ -383,7 +383,7 @@
 <p>
 The netlist assumes element refdes are unique. If an element has multiple
 instances of the same pin (or pad) number, the engine picks one randomly and
-assumes there's an inivisible, internal connection within the element.
+assumes there's an invisible, internal connection within the element.
 <p>
 Rat lines can be regenerated from the current netlist for missing connections.
 Connections that are realized in copper but not present on the netlist, pcb-rnd
@@ -408,7 +408,7 @@
 <h3> 2.5. comparison of terms </h3>
 <p>
 <table border=1>
-	<tr><th> phyisical board term    <th> pcb-rnd term
+	<tr><th> physical board term     <th> pcb-rnd term
 	<tr><td> layer                   <td> layer group
 	<tr><td> copper layer            <td> layer group with copper layers
 	<tr><td> substrate               <td> N/A
Index: trunk/doc/user/04_ui/01_gtk/index.html
===================================================================
--- trunk/doc/user/04_ui/01_gtk/index.html	(revision 5702)
+++ trunk/doc/user/04_ui/01_gtk/index.html	(revision 5703)
@@ -20,7 +20,7 @@
 	<li><a href="#coordinates readout">Coordinates Readout
 	<li><a href="#route styles ">Route Styles
 	<li><a href="#ops readout">Ops Readout
-	<li><a href="#key-commands">Key Commans
+	<li><a href="#key-commands">Key Commands
 	<li><a href="#gui-cli">Gui Command Line Interface
 	<li><a href="#dialog-windows">Dialog Windows 
 		<ul>
@@ -43,7 +43,7 @@
 <ul>
 <li>File - standard file operations -pcb-rnd import/export,  and preferences access
 <li>Edit - a little of everything, undos, buffer ops, selection, edit name and route styles, 
-<li>View - main view grid control and attribute visibiility
+<li>View - main view grid control and attribute visibility
 <li>Settings - lots of things
 <li>Select - selection and edit selection control
 <li>Buffer - edit, select, place, transform buffer contents
@@ -60,7 +60,7 @@
 Readouts give live info for the user: 
 Obtain absolute and relative coordinate information
 <h3><a name="route-styles">Route Styles<p></a></h3>
-Acess route style dialog and alter existing route style 
+Access route style dialog and alter existing route style 
 <h3><a name="ops-readout">Ops Readout<p></a></h3>
 Readouts provide live info for the user
 Obtain view grid line drawing style reporter, via size, clearance value, text
Index: trunk/doc/user/06_feature/gpmi/packages/actions.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/actions.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/actions.html	(revision 5703)
@@ -55,7 +55,7 @@
 
 <H2> Executing actions </H2>
 An existing action can be executed using the action() call. The only one
-argument is a command line string. The syntyax is the same as in pcb
+argument is a command line string. The syntax is the same as in pcb
 command line.
 
 Example (written in lua):
@@ -72,7 +72,7 @@
 </PRE>
 <p>
 The above script registers a new action called untwo(). When untwo() is executed,
-it exectues action undo() twice.
+it executes action undo() twice.
 
 
 <H2> Creating menus </H2>
Index: trunk/doc/user/06_feature/gpmi/packages/actions_ref.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/actions_ref.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/actions_ref.html	(revision 5703)
@@ -12,7 +12,7 @@
 <pre>
  Generated when an action registered by the script is executed.
    Arguments:
-    name: name of the action (as registed using function action_register())
+    name: name of the action (as registered using function action_register())
     argc: number of arguments. Arguments can be accessed using function action_arg
     x, y: optional coords, if need_xy was not empty at action_register 
 </pre>
@@ -30,7 +30,7 @@
  Generated right before unloading a script to give the script a chance
    to clean up.
    Arguments:
-    conffile: the name of the config file that originally triggered laoding the script, or empty if the script was loaded from the gui. 
+    conffile: the name of the config file that originally triggered loading the script, or empty if the script was loaded from the gui. 
 </pre>
 </dl>
 <h3> Functions </h3>
Index: trunk/doc/user/06_feature/gpmi/packages/dialogs.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/dialogs.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/dialogs.html	(revision 5703)
@@ -32,7 +32,7 @@
 
 	<H2> Progress dialogs </H2>
 
-	The script should call dialog_progress() periodicly from a process that
+	The script should call dialog_progress() periodically from a process that
 	runs time consuming calculations and check the return value and break
 	the loop on cancel. The process should have an idea of how long it
 	will take. This is passed on in argument <i>total</i>. As long as
Index: trunk/doc/user/06_feature/gpmi/packages/dialogs_ref.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/dialogs_ref.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/dialogs_ref.html	(revision 5703)
@@ -96,7 +96,7 @@
    Arguments:
      hid: widgets
      title: title of the window
-     descr: descripting printed in the dialog 
+     descr: description printed in the dialog 
 </pre>
 </dl>
 
Index: trunk/doc/user/06_feature/gpmi/packages/hid.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/hid.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/hid.html	(revision 5703)
@@ -10,7 +10,7 @@
 
 <H2> Building a custom dialog box</H2>
 First hid_create() needs to be called. It returns a new hid_t, which is
-an opaq structure for the package that is used to describe attributes of
+an opaque structure for the package that is used to describe attributes of
 an attribute dialog or an exporter hid. Attributes are added using
 hid_add_attribute(), which returns an unique ID of the attribute. The
 attribute ID can be used later for querying attribute value set by the
@@ -26,7 +26,7 @@
 
 <H2> Registering an exporter</H2>
 	Function hid_register() registers the hid as an exporter. Should be
-	called after all attributes have been added using hid_add_atrtibute().
+	called after all attributes have been added using hid_add_attribute().
 	The export is coordinated by pcb core; when the user request an export
 	using the exporter, a series of events are delivered to the script:
 	<ol>
@@ -39,7 +39,7 @@
 		<UL>
 			<LI>HIDE_get_export_options(void *hid): Generated before get_exporter_options returns the option list to the GUI hid
 			<LI>HIDE_do_export_start(void *hid): Generated before export redraw starts
-			<LI>HIDE_do_export_finish(void *hid): Generated after export redraw finihsed
+			<LI>HIDE_do_export_finish(void *hid): Generated after export redraw finished
 		</UL>
 
 	<H3> Drawing: events generated during exporting </H3>
Index: trunk/doc/user/06_feature/gpmi/packages/hid_ref.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/hid_ref.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/hid_ref.html	(revision 5703)
@@ -15,7 +15,7 @@
 <table border=1>
 <tr><th>value <th>meaning
 <tr><td> HIDA_Label <td>  non-editable label displayed on the GUI 
-<tr><td> HIDA_Integer <td>  a sugned integer value 
+<tr><td> HIDA_Integer <td>  a signed integer value 
 <tr><td> HIDA_Real <td>  a floating point value 
 <tr><td> HIDA_String <td>  one line textual input 
 <tr><td> HIDA_Boolean <td>  true/false boolean value 
@@ -54,7 +54,7 @@
 <a id="HIDE_do_export_finish">
 <H4> HIDE_do_export_finish(int event_id, void* hid) </H4>
 <pre>
- Called after export redraw finihsed 
+ Called after export redraw finished 
 </pre>
 <a id="HIDE_set_layer">
 <H4> HIDE_set_layer(int event_id, void* hid, const char* name, int group, int empty) </H4>
@@ -109,7 +109,7 @@
 <a id="HIDE_fill_polygon">
 <H4> HIDE_fill_polygon(int event_id, void* hid, void* gc, int n_coords, int* x, int* y) </H4>
 <pre>
- PCB callback events for drawing: draw a filled ploygon 
+ PCB callback events for drawing: draw a filled polygon 
 </pre>
 <a id="HIDE_fill_rect">
 <H4> HIDE_fill_rect(int event_id, void* hid, void* gc, int x1, int y1, int x2, int y2) </H4>
Index: trunk/doc/user/06_feature/gpmi/packages/layout.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/layout.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/layout.html	(revision 5703)
@@ -43,11 +43,11 @@
 to access fields of an object structure.
 
 <H2>Create new objects </H2>
-	The layour_create_*() calls are used to create new objects on the current
+	The layout_create_*() calls are used to create new objects on the current
 	layer (set by layout_switch_to_layer()). 
 
 
-<H2> API reference - page, untis and coordinates </H2>
+<H2> API reference - page, units and coordinates </H2>
 (angles are in radian)
 TODO
 
Index: trunk/doc/user/06_feature/gpmi/packages/layout_ref.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/packages/layout_ref.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/packages/layout_ref.html	(revision 5703)
@@ -161,7 +161,7 @@
 <a id="layout_arc_angles">
 <H4>  int layout_arc_angles(layout_object_t* obj, int relative, int start, int delta)  </H4>
 <pre>
- change angles of an arc; start and delate are relative if relative is non-zero; returns 0 on success 
+ change angles of an arc; start and delta are relative if relative is non-zero; returns 0 on success 
 </pre>
 <a id="layout_create_line">
 <H4>  int layout_create_line(int x1, int y1, int x2, int y2, int thickness, int clearance, layout_flag_t flags)  </H4>
Index: trunk/doc/user/06_feature/gpmi/rosetta/30_move/ex.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/rosetta/30_move/ex.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/rosetta/30_move/ex.html	(revision 5703)
@@ -17,7 +17,7 @@
 </ul>
 A loop then iterates over the objects on the list:
 <ul>
-	<li> resolve the Nth element of the list using <ref>layout_search_get</ref>, referecing the list by name ("mv_search") and specifying which element to get (the Nth); the result is an object pointer;
+	<li> resolve the Nth element of the list using <ref>layout_search_get</ref>, referencing the list by name ("mv_search") and specifying which element to get (the Nth); the result is an object pointer;
 	<li> move the object using <ref>layout_obj_move</ref>; specify the object pointer, then which part of the object should be moved ("OC_OBJ" means the whole object) and relative offsets (dx and dy calculated earlier)
 </ul>
 Finally the search list shall be destroyed to reclaim memory, using <ref>layout_search_free</ref>.
Index: trunk/doc/user/06_feature/gpmi/rosetta/30_move/index.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/rosetta/30_move/index.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/rosetta/30_move/index.html	(revision 5703)
@@ -49,7 +49,7 @@
 <ul> 	
 <li> resolve the Nth element of the list using 
 <i><a href="../../packages/layout_ref.html#layout_search_get">layout_search_get</a></i>
-, referecing the list by name ("mv_search") and specifying which element to get (the Nth); the result is an object pointer; 	
+, referencing the list by name ("mv_search") and specifying which element to get (the Nth); the result is an object pointer; 	
 <li> move the object using 
 <i><a href="../../packages/layout_ref.html#layout_obj_move">layout_obj_move</a></i>
 ; specify the object pointer, then which part of the object should be moved ("OC_OBJ" means the whole object) and relative offsets (dx and dy calculated earlier) </ul>
Index: trunk/doc/user/06_feature/gpmi/scripting_intro.html
===================================================================
--- trunk/doc/user/06_feature/gpmi/scripting_intro.html	(revision 5702)
+++ trunk/doc/user/06_feature/gpmi/scripting_intro.html	(revision 5703)
@@ -221,6 +221,6 @@
 # load the carc script (written in lua) from next to the config file:
 lua carc.lua
 
-# load foo.awk, whcih is a mawk script, from its installation path
+# load foo.awk, which is a mawk script, from its installation path
 mawk /usr/lib/foo/foo.awk
 </pre>
Index: trunk/doc/user/06_feature/query/tutor_cli.html
===================================================================
--- trunk/doc/user/06_feature/query/tutor_cli.html	(revision 5702)
+++ trunk/doc/user/06_feature/query/tutor_cli.html	(revision 5703)
@@ -5,7 +5,7 @@
 
 <h2> scope </h2>
 
-pcb-rnd from version 1.1.3 features a flexible advnced search that helps
+pcb-rnd from version 1.1.3 features a flexible advanced search that helps
 the user selecting/unselecting objects that match a given logical expression.
 The core of the feature is the pcb-rnd query language. The same language
 is used in the programmable DRC (see also: <a href="../../../developer/ddrc/proposal1.txt">
@@ -38,7 +38,7 @@
 <pre>
 query(select, '@')
 </pre>
-The actual query experssion was a single @ in this case. This made
+The actual query expression was a single @ in this case. This made
 the iteration happen, got the expression evaluated one each object. The
 result of each evaluation was the given object. Since these objects
 were all existing, valid objects, they were taken as logical value TRUE,
@@ -67,7 +67,7 @@
 query(eval, '1')
 </pre>
 This will calculate the value of 1 and prints it to the standard output. Since
-theres no iteration, this can not result in changes in selection. However,
+there's no iteration, this can not result in changes in selection. However,
 it makes it easy to demonstrate some basic concepts of the query language.
 <p>
 Note: if @ is present multiple times in the expression, it's still only
@@ -92,7 +92,7 @@
 	<tr><td>1 &amp;&amp; 0<td> 0   <td> logical AND - the result is 1 if both operands were TRUE, 0 else
 	<tr><td>1 || 0     <td> 1      <td> logical OR  - the result is 1 if either operand was TRUE, 0 else
 	<tr><td>!2         <td> 0      <td> logical NOT - 2 is non-zero, so it is TRUE, negate this to get the result (FALSE, which is 0)
-	<tr><td>4 > 2      <td> 1      <td> because four is greater than two; all the usual relational operats work: == is equal, != is not-equal, &lt;, &lt=,  &gt; and &gt=.
+	<tr><td>4 > 2      <td> 1      <td> because four is greater than two; all the usual relational operators work: == is equal, != is not-equal, &lt;, &lt=,  &gt; and &gt=.
 </table>
 
 <H2> grammar: object properties </h2>
@@ -119,7 +119,7 @@
 	(@.thickness &lt; 10 mil) || (@.thickness &gt; 30 mil)
 </pre>
 <p>
-or traces that don't match our preferred 8, 10 and 15 mil thicnkess values:
+or traces that don't match our preferred 8, 10 and 15 mil thickness values:
 <pre>
 	(@.thickness != 8 mil) &amp;&amp; (@.thickness != 10 mil) &amp;&amp; (@.thickness != 15 mil)
 </pre>
@@ -158,11 +158,11 @@
 Referencing non-existing properties yields an error, e.g. @.thickness.layer
 is an error - in contrast with @.layer, which may evaluate to the
 <i>invalid value</i> (e.g. for vias or nets, because they don't have layers).
-The difference is that tickness can not have a layer ever (thus is an error)
+The difference is that thickness can not have a layer ever (thus is an error)
 while @.layer is either applicable or not, but potentially could work, this
 when it doesn't, it's only an invalid value.
 <p>
-Further useful property combinatons:
+Further useful property combinations:
 TODO
 <p>
 There is a <a href="props.html">full list of all properties</a>.