Some minor documentation edits

documentation/src/api_architecture.rst

@@ -19,8 +19,8 @@ form. The user interfaces are located in `scripts/`. Currently there is
 Generators
 ..........
 
-A (box) generator is an subclass of boxes.Boxes. It generates one
-drawing. The subclasses over load .__init__() to set their parameters
+A (box) generator is a subclass of boxes.Boxes. It generates one
+drawing. The subclasses overload .__init__() to set their parameters
 and implement .render() that does the actual drawing.
 
 Generators are found in ``boxes/generators/``. They are included into
@@ -33,18 +33,19 @@ Parts
 .....
 
 Parts are a single call that draws something according to a set of parameters.
-There is a number of standard parts. Their typical params are
+There are a number of standard parts. Their typical params are
 explained in the API docs.
 
-Only real requirement for a part it supporting the move parameter for
-placement.
+The only real requirement for a part is that it must support the move
+parameter for placement.
 
 Part Callbacks
 ++++++++++++++
 
 Most parts support callbacks - either one in the middle for round
 parts or one for each edge. They allow placing holes or other features
-on the part.
+on the part, indepenent of edge type.  Without using callbacks, you
+will not have consistent placement of internal features.
 
 Navigation and Turtle Graphics
 ..............................

documentation/src/api_arguments.rst

@@ -71,6 +71,6 @@ Accessing the Arguments
 For convenience content of the arguments are written to attributes of
 the Boxes instance before ``.render()`` is called. This is done by
 ``Boxes.parseArgs``. But most people won't need to care as this is
-handled by the frame work.  Be careful to **not overwrite important
+handled by the framework.  Be careful to **not overwrite important
 methods or attributes by using conflicting argument names**.
 

documentation/src/api_burn.rst

@@ -34,17 +34,18 @@ cutting this deemed acceptable for a long time:
 Programmer's perspective
 ------------------------
 
-For this to work it is important that outside is drawn in a counter
-clock wise direction while holes are drawn in a clock wise direction. 
+For this to work it is important that outside is drawn in a
+counterclockwise direction while holes are drawn in a 
+clockwise direction. 
 
 :py:meth:`boxes.Boxes.corner` adjusts the radius automatically
 according to **.burn**. This propagates to higher level
 functions. Parts shipped with Boxes.py do take the
-burn out-set into account and execute callbacks at the correct position.
+burn outset into account and execute callbacks at the correct position.
 
 In case developers move to a feature inside of a part or executing
 callbacks while implementing a part they need to be aware of the burn
-correction. :py:meth:`boxes.Boxes.cc` does correct for the out-set if
+correction. :py:meth:`boxes.Boxes.cc` does correct for the outset if
 called without an **y** parameter. But if a value is given one has to
 add **self.burn** to compensate. Note that the **x** value typically
 does not have to be corrected as the callbacks are executed from right
@@ -52,7 +53,7 @@ underneath the part.
 
 A similar approach is necessary when moving to a feature drawn inside
 the part without the use of callbacks. Here you typically have to
-correct for the out-set at the outside of the part and again for in-set
+correct for the outset at the outside of the part and again for inset
 of the hole one is about to cut. This can be done in **x** or **y**
 direction depending on whether the cut is started vertical or
 horizontally.

documentation/src/api_edges.rst

@@ -7,11 +7,11 @@ of Boxes.py. This means they start at the current position and current
 direction and move the current position to the end of the edge.
 
 Edge instances have a Settings object associated with them that keeps
-the details about how the edge should look like. Edges that are
+the details about what the edge should look like. Edges that are
 supposed to work together share the same Settings object to ensure
 they fit together - assuming they have the same length. Most edges are
-symmetrical to unsure they fit together even when drawn from different
-directions. Although there are a few exception - mainly edges that
+symmetrical to ensure they fit together even when drawn from different
+directions. Although there are a few exceptions - mainly edges that
 provide special features like hinges.
 
 As edges started out as methods of the main Boxes class they still are
@@ -19,13 +19,13 @@ callables. It turned out that the edges need to provide a bit more
 information to allow the surrounding code to handle them
 properly. When drawing an Edge there is a virtual straight line that
 is the border the shape of the part (e.g. an rectangle). But the
-actual Edge has often to be drawn elsewhere. Best example if probably
+actual Edge often has to be drawn elsewhere. The best example is probably
 the ``F`` Edge that matches the normal finger joints. It has to start
 one material thickness outside of the virtual border of the part so the
 cutouts for the opposing fingers just touch the border. The Edge
-classes have a number of methods to deal with these kind of offsets.
+classes have a number of methods to deal with these kinds of offsets.
 
-A set of instances are kept the ``.edges`` attribute of the
+A set of instances are kept in the ``.edges`` attribute of the
 ``Boxes`` class. It is a dict with strings of length one as keys:
 
 * aAbB : reserved to be used in generators
@@ -140,7 +140,7 @@ Bed Bolts
 
 .. autoclass:: boxes.edges.Bolts
 
-Dove Tail Joints
+Dovetail Joints
 ----------------
 Dovetails joints can only be used to join two pieces flatly. This
 limits their use to closing some round form created with flex areas or
@@ -150,7 +150,7 @@ much stronger than simple finger joints and can also bare pulling forces.
 .. autoclass:: boxes.edges.DoveTailJoint
 .. autoclass:: boxes.edges.DoveTailJointCounterPart
 
-Dove Tail Settings
+Dovetail Settings
 ..................
 
 .. autoclass:: boxes.edges.DoveTailSettings

documentation/src/api_examples.rst

@@ -40,8 +40,8 @@ DisplayShelf
 .. autoclass:: boxes.generators.displayshelf.DisplayShelf
 
 The DisplayShelf is completely made out of rectangularWalls(). It uses
-a callback to place all the fingerHolesAt() right places on the sides.
-While the use of the Boxes.py API is pretty straight forward the
+a callback to place all the fingerHolesAt() at the right places on the sides.
+While the use of the Boxes.py API is pretty straightforward the
 calculations needed are a bit more tricky. You can use the ``debug``
 default param to check if you got things right when attempting
 something like this yourself.

documentation/src/api_navigation.rst

@@ -8,11 +8,11 @@ last line. Other drawing commands restore the current position after
 they are finished.
 
 Moving the origin like this allows ignoring the absolute coordinates
-and do all movement and drawing to be relative to the current
-position. The current positions does not only consist of a point on
+and for all movement and drawing to be relative to the current
+position. The current position not only consists of a point on
 the drawing canvas but also a direction.
 
-To move the origin to a different location there are these to methods:
+To move the origin to a different location there are these two methods:
 
 .. automethod:: boxes.Boxes.moveTo
 .. automethod:: boxes.Boxes.moveArc

documentation/src/api_parts.rst

@@ -4,7 +4,7 @@ Parts
 
 
 
-There are a few parameter shared by many of those parts:
+There are a few parameters shared by many of the parts:
 
 The callback parameter
 ......................
@@ -78,9 +78,9 @@ denominate single edge (types) only.
 PartsMatrix
 ...........
 
-To place many of the same part partMatrix can used:
+To place a grid of identical parts, partMatrix can used:
 
 .. automethod:: boxes.Boxes.partsMatrix
 
-It creates one big block of parts. The move param treat this block like on big
+It creates one big block of parts. The move param treats this block like one big
 part.