Fix typos

3 files changed, 31 insertions, 31 deletions

diff --git a/Doc/Manual/Introduction.html b/Doc/Manual/Introduction.html
index a8d15a5c2..d5dc778bd 100644
--- a/Doc/Manual/Introduction.html
+++ b/Doc/Manual/Introduction.html
@@ -38,7 +38,7 @@
 SWIG is a software development tool that simplifies the task of
 interfacing different languages to C and C++ programs.  In a
 nutshell, SWIG is a compiler that takes C/C++ declarations and creates
-the wrappers needed to access those declarations from other languages including
+the wrappers needed to access those declarations from other languages
 including Perl, Python, Tcl, Ruby, Guile, and Java.  SWIG normally
 requires no modifications to existing code and can often be used to
 build a usable interface in only a few minutes.  Possible applications
@@ -49,7 +49,7 @@ of SWIG include:
 <li>Building interpreted interfaces to existing C programs.
 <li>Rapid prototyping and application development.
 <li>Interactive debugging.
-<li>Reengineering or refactoring of legacy software into a scripting language components.
+<li>Reengineering or refactoring of legacy software into scripting language components.
 <li>Making a graphical user interface (using Tk for example).
 <li>Testing of C libraries and programs (using scripts).
 <li>Building high performance C modules for scripting languages.
@@ -98,7 +98,7 @@ of other libraries).
 <li>Testing is time consuming (the compile/debug cycle).
 <li>Not easy to reconfigure or customize without recompilation.
 <li>Modularization can be tricky.
-<li>Security concerns (buffer overflow for instance).
+<li>Security concerns (buffer overflows for instance).
 </ul>
 <p>
 To address these limitations, many programmers have arrived at the
@@ -345,7 +345,7 @@ not only parses C++, it implements the full C++ type system and it is
 able to understand C++ semantics.  SWIG generates its wrappers with
 full knowledge of this information.  As a result, you will find SWIG
 to be just as capable of dealing with nasty corner cases as it is in
-wrapping simple C++ code.  In fact, SWIG is able handle C++ code that
+wrapping simple C++ code.  In fact, SWIG is able to handle C++ code that
 stresses the very limits of many C++ compilers.
 
 
@@ -388,8 +388,8 @@ There is growing support for SWIG in some build tools, for example <a href="http
 is a cross-platform, open-source build manager with built in support for SWIG. CMake can detect the SWIG executable
 and many of the target language libraries for linking against.
 CMake knows how to build shared libraries and loadable modules on many different operating systems.
-This allows easy cross platform SWIG development.  It also can generate the custom commands necessary for
-driving SWIG from IDE's and makefiles.  All of this can be done from a single cross platform input file.
+This allows easy cross platform SWIG development.  It can also generate the custom commands necessary for
+driving SWIG from IDEs and makefiles.  All of this can be done from a single cross platform input file.
 The following example is a CMake input file for creating a python wrapper for the SWIG interface file, example.i:
 </p>
 
diff --git a/Doc/Manual/SWIG.html b/Doc/Manual/SWIG.html
index c0cde0172..bd929f7d4 100644
--- a/Doc/Manual/SWIG.html
+++ b/Doc/Manual/SWIG.html
@@ -224,7 +224,7 @@ $ swig -c++ -python -o example_wrap.cpp example.i
 
 <p>
 The C/C++ output file created by SWIG often
-contains everything that is needed to construct a extension module
+contains everything that is needed to construct an extension module
 for the target scripting language. SWIG is not a stub compiler nor is it
 usually necessary to edit the output file (and if you look at the output,
 you probably won't want to). To build the final extension module, the
@@ -233,7 +233,7 @@ program to create a shared library.
 </p>
 
 <p>
-Many target languages will also generate proxy class files in the
+For many target languages SWIG will also generate proxy class files in the
 target language. The default output directory for these language 
 specific files is the same directory as the generated C/C++ file. This
 can be modified using the <tt>-outdir</tt> option. For example:
@@ -484,7 +484,7 @@ Or in Python:
 Whenever possible, SWIG creates an interface that closely matches the underlying C/C++
 code. However, due to subtle differences between languages, run-time
 environments, and semantics, it is not always possible to do so.   The
-next few sections describes various aspects of this mapping.
+next few sections describe various aspects of this mapping.
 </p>
 
 <H3><a name="SWIG_nn10"></a>5.2.1 Basic Type Handling</H3>
@@ -728,7 +728,7 @@ However, for the same conservative reasons even a constant with a simple cast wi
 
 <div class="code">
 <pre>
-#define F_CONST (double) 5            // A floating pointer constant with cast
+#define F_CONST (double) 5            // A floating point constant with cast
 </pre>
 </div>
 
@@ -750,7 +750,7 @@ enum values as assigned by the C compiler.
 <p>
 The <tt>%constant</tt> directive is used to more precisely create
 constants corresponding to different C datatypes.  Although it is not
-usually not needed for simple values, it is more useful when working
+usually needed for simple values, it is more useful when working
 with pointers and other more complex datatypes.  Typically, <tt>%constant</tt>
 is only used when you want to add constants to the scripting language
 interface that are not defined in the original header file. 
@@ -868,7 +868,7 @@ from a scripting language to a C <tt>char *</tt>, the pointer usually
 points to string data stored inside the interpreter.  It is almost
 always a really bad idea to modify this data.  Furthermore, some
 languages may explicitly disallow it.  For instance, in Python,
-strings are supposed be immutable.   If you violate this, you will probably
+strings are supposed to be immutable.   If you violate this, you will probably
 receive a vast amount of wrath when you unleash your module on the world.
 </p>
 
@@ -1483,7 +1483,7 @@ void transpose(double (*a)[20]);
 <p>
 Like C, SWIG does not perform array bounds checking.  
 It is up to the
-user to make sure the pointer points a suitably allocated region of memory. 
+user to make sure the pointer points to a suitably allocated region of memory. 
 </p>
 
 <p>
@@ -2265,7 +2265,7 @@ disabled using <tt>%nocallback</tt>.  When you do this, the interface now works
 
 <p>
 Notice that when the function is used as a callback, special names
-such as <tt>add_cb</tt> is used instead.  To call the function
+such as <tt>add_cb</tt> are used instead.  To call the function
 normally, just use the original function name such as <tt>add()</tt>.
 </p>
 
@@ -2311,7 +2311,7 @@ handle C++ are described in the next section.
 If SWIG encounters the definition of a structure or union, it
 creates a set of accessor functions. Although SWIG does not need
 structure definitions to build an interface, providing definitions
-make it possible to access structure members. The accessor functions
+makes it possible to access structure members. The accessor functions
 generated by SWIG simply take a pointer to an object and allow access
 to an individual member. For example, the declaration :</p>
 
@@ -2434,7 +2434,7 @@ vector_struct</tt>, SWIG knows that this is the same as
 Structures involving character strings require some care. SWIG assumes
 that all members of type <tt>char *</tt> have been dynamically
 allocated using <tt>malloc()</tt> and that they are NULL-terminated
-ASCII strings. When such a member is modified, the previously contents
+ASCII strings. When such a member is modified, the previous contents
 will be released, and the new contents allocated. For example :</p>
 
 <div class="code"><pre>
@@ -2519,7 +2519,7 @@ typedef struct Bar {
 <p>
 When a structure member is wrapped, it is handled as a pointer, unless the <tt>%naturalvar</tt> directive
 is used where it is handled more like a C++ reference (see <a href="SWIGPlus.html#SWIGPlus_member_data">C++ Member data</a>).
-The accessors to the member variable as a pointer is effectively wrapped as follows:
+The accessors to the member variable as a pointer are effectively wrapped as follows:
 </p>
 
 <div class="code">
@@ -2656,8 +2656,8 @@ struct Bar {             // Default constructor generated.
 
 
 <p>
-Since ignoring the implicit or default destructors most of the times
-produce memory leaks, SWIG will always try to generate them. If
+Since ignoring the implicit or default destructors most of the time
+produces memory leaks, SWIG will always try to generate them. If
 needed, however, you can selectively disable the generation of the
 default/implicit destructor by using <tt>%nodefaultdtor</tt>
 </p>
@@ -2687,7 +2687,7 @@ has now been enabled as the default behavior.
 <b>Note:</b> There are also the <tt>-nodefault</tt> option and
 <tt>%nodefault</tt> directive, which disable both the default or
 implicit destructor generation. This could lead to memory leaks across 
-the target languages, and is highly recommended you don't use them.
+the target languages, and it is highly recommended you don't use them.
 </p>
 
 
@@ -3280,7 +3280,7 @@ initialization on module loading, you could write this:
 
 
 <p>
-This section describes the general approach for building interface
+This section describes the general approach for building interfaces
 with SWIG. The specifics related to a particular scripting language
 are found in later chapters.</p>
 
@@ -3295,9 +3295,9 @@ of steps you can follow to make an interface for a C program :</p>
 
 <ul>
 <li>Identify the functions that you want to wrap. It's probably not
-necessary to access every single function in a C program--thus, a
+necessary to access every single function of a C program--thus, a
 little forethought can dramatically simplify the resulting scripting
-language interface. C header files are particularly good source for
+language interface. C header files are a particularly good source for
 finding things to wrap.
 
 <li>Create a new interface file to describe the scripting language
@@ -3342,7 +3342,7 @@ to the <a href="http://www.swig.org/mail.html">swig-devel mailing list</a> or to
 
 
 <p>
-The preferred method of using SWIG is to generate separate interface
+The preferred method of using SWIG is to generate a separate interface
 file. Suppose you have the following C header file :</p>
 
 <div class="code"><pre>
@@ -3436,7 +3436,7 @@ include certain header files by using a <tt>%{,%}</tt> block like this:
 #include &lt;GL/glu.h&gt;
 %}
 
-// Put rest of declarations here
+// Put the rest of the declarations here
 ...
 </pre></div>
 
@@ -3478,7 +3478,7 @@ program that is more interactive. In many cases, the old
 or Tcl script.</p>
 
 <p>
-<b>Note:</b> If some cases, you might be inclined to create a
+<b>Note:</b> In some cases, you might be inclined to create a
 scripting language wrapper for <tt>main()</tt>.  If you do this, the
 compilation will probably work and your module might even load
 correctly.  The only trouble is that when you call your
diff --git a/Doc/Manual/Scripting.html b/Doc/Manual/Scripting.html
index e6a2eee24..26a8dd017 100644
--- a/Doc/Manual/Scripting.html
+++ b/Doc/Manual/Scripting.html
@@ -293,7 +293,7 @@ A proxy class is a special kind of object that gets created
 in a scripting language to access a C/C++ class (or struct) in a way
 that looks like the original structure (that is, it proxies the real
 C++ class). For example, if you
-have the following C definition :</p>
+have the following C++ definition :</p>
 
 <div class="code"><pre>
 class Vector {
@@ -334,12 +334,12 @@ Finally, in Tcl :
 
 <div class="targetlang"><pre>
 Vector v
-v configure -x 3 -y 4 -z 13
+v configure -x 3 -y 4 -z -13
 
 </pre></div>
 
 <p>
-When proxy classes are used, two objects are at really work--one in
+When proxy classes are used, two objects are really at work--one in
 the scripting language, and an underlying C/C++ object. Operations
 affect both objects equally and for all practical purposes, it appears
 as if you are simply manipulating a C/C++ object. 
@@ -353,7 +353,7 @@ The final step in using a scripting language with your C/C++
 application is adding your extensions to the scripting language
 itself. There are two primary approaches for doing
 this. The preferred technique is to build a dynamically loadable
-extension in the form a shared library.  Alternatively, you can
+extension in the form of a shared library.  Alternatively, you can
 recompile the scripting language interpreter with your extensions
 added to it.
 </p>
@@ -364,7 +364,7 @@ added to it.
 <p>
 To create a shared library or DLL, you often need to look at the
 manual pages for your compiler and linker.  However, the procedure
-for a few common machines is shown below:</p>
+for a few common platforms is shown below:</p>
 
 <div class="shell"><pre>
 # Build a shared library for Solaris