diff --git a/org.jacoco.doc/docroot/doc/agent.html b/org.jacoco.doc/docroot/doc/agent.html
index 1f314bd..da0b591 100644
--- a/org.jacoco.doc/docroot/doc/agent.html
+++ b/org.jacoco.doc/docroot/doc/agent.html
@@ -18,7 +18,7 @@
 
 <p>
   JaCoCo uses class file instrumentation to record execution coverage data.
-  Class files are instrumented on-the-fly using a so called Java agent. This is
+  Class files are instrumented on-the-fly using a so called Java agent. This
   mechanism allows in-memory pre-processing of all class files during class
   loading independent of the application framework. The JaCoCo agent collects
   execution information and dumps it to a local file when the JVM exits.
@@ -26,8 +26,8 @@
 
 <p class="hint">
   If you use the <a href="ant.html">JaCoCo Ant tasks</a> you don't have to care
-  about the agent and its options directly. All set-up is transparently handled
-  by the Ant tasks implementation.
+  about the agent and its options directly. This is transparently handled by the
+  Ant tasks.
 </p>
 
 <p>
@@ -68,7 +68,7 @@
     </tr>    
     <tr>
       <td><code>includes</code></td>
-      <td>A list of class names that should be included to execution analysis.
+      <td>A list of class names that should be included in execution analysis.
           The list entries are separated by a vertical bar (<code>|</code>) and
           may use wildcard characters (<code>*</code> and <code>?</code>).
           Except for performance optimization or technical corner cases this
diff --git a/org.jacoco.doc/docroot/doc/ant.html b/org.jacoco.doc/docroot/doc/ant.html
index 411d23c..55824b5 100644
--- a/org.jacoco.doc/docroot/doc/ant.html
+++ b/org.jacoco.doc/docroot/doc/ant.html
@@ -91,9 +91,9 @@
 </pre>
 
 <p>
-  As a result coverage information is collected during execution and written
-  to a file when the process terminates. Note the <code>fork</code> attribute in
-  wrapped <code>java</code> task. 
+  Resulting coverage information is collected during execution and written
+  to a file when the process terminates. Note the <code>fork</code> attribute
+  above in the wrapped <code>java</code> task. 
 </p>
 
 <p class="hint">
@@ -134,7 +134,7 @@
     </tr>    
     <tr>
       <td><code>includes</code></td>
-      <td>A list of class names that should be included to execution analysis.
+      <td>A list of class names that should be included in execution analysis.
           The list entries are separated by a vertical bar (<code>|</code>) and
           may use wildcard characters (<code>*</code> and <code>?</code>).
           Except for performance optimization or technical corner cases this
@@ -174,7 +174,7 @@
   If the <code>coverage</code> task is not suitable for your launch target, you
   might alternatively use the <code>agent</code> task to create the Java agent
   parameter. The following example defines a Ant property with the name
-  <code>agentvmparam</code> that can be directly used as Java VM parameter:
+  <code>agentvmparam</code> that can be directly used as a Java VM parameter:
 </p>
 
 <pre class="source">
@@ -246,14 +246,13 @@
   Within this element Ant resources and resource collections can be specified,
   that represent JaCoCo execution data files. If more than one execution data
   file is specified, execution data is combined. A particular piece of code is
-  considered as executed, when it is marked as executed in any of the input
-  files.
+  considered executed when it is marked as such in any of the input files.
 </p>
 
 <h3>Element <code>structure</code></h3>
 
 <p>
-  This element defines structure of the report. It might contain the following
+  This element defines the report structure. It might contain the following
   nested elements:
 </p>
 
@@ -266,14 +265,14 @@
     has an optional attribute <code>encoding</code> to specify the character
     encoding of the source files. If no encoding is given, the platform default
     is used. If source files are specified, some report formats include
-    highlighted versions of the source code.</li>
+    highlighted source code.</li>
 </ul>
 
 <p>
   The structure can be refined with a hierarchy of <code>group</code> elements.
-  This way the coverage report can reflect different modules of an software
+  This way the coverage report can reflect different modules of a software
   project. For each group element the corresponding class and source files can
-  be specified separately. For example the build script of JaCoCo itself
+  be specified separately. For example, the build script of JaCoCo itself
   contains the following declaration to separate the different bundles in the
   report (see the <a href="../coverage/index.html">resulting report</a>): 
 </p>
diff --git a/org.jacoco.doc/docroot/doc/build.html b/org.jacoco.doc/docroot/doc/build.html
index 92d2ecd..c800695 100644
--- a/org.jacoco.doc/docroot/doc/build.html
+++ b/org.jacoco.doc/docroot/doc/build.html
@@ -109,7 +109,7 @@
   more. The reason is the code assist function for user defined tasks. Please
   see the
   <a href="http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.user/reference/ref-antcodeassist.htm">Eclipse reference</a>
-  how to configure the Ant Editor to avoid these locks.
+  on how to configure the Ant Editor to avoid these locks.
 </p>
 
 
@@ -169,7 +169,7 @@
 </p>
 
 <p class="hint">
-  The file <code>build.properties</code> files are part of the Eclipse PDE
+  The file <code>build.properties</code> is part of the Eclipse PDE
   declarations and not (yet) used by the JaCoCo Ant build.
 </p>
 
@@ -177,7 +177,7 @@
 <h2>Internal Structure of the Build</h2>
 
 <p>
-  JaCoCo is build with a set of custom Ant scripts that can be easily executed
+  JaCoCo is built by a set of custom Ant scripts that can be easily executed
   on different machines. While the modularization mechanism is based on OSGi
   bundles, the build does not (yet) use a build system like PDE build or Maven.
   The reason is that some JaCoCo artifacts like the <code>agent.jar</code> have
diff --git a/org.jacoco.doc/docroot/doc/counters.html b/org.jacoco.doc/docroot/doc/counters.html
index 9fcc12e..9373390 100644
--- a/org.jacoco.doc/docroot/doc/counters.html
+++ b/org.jacoco.doc/docroot/doc/counters.html
@@ -29,9 +29,12 @@
 <h2>Basic Blocks</h2>
 
 <p>
-  Basic blocks &ndash; mostly just referred to as <i>blocks</i> in the APIs and
-  reports &ndash; are consecutive sequences of byte code instructions that will
-  normally only executed on-block. The boundaries between blocks are
+  A basic block &ndash; mostly just referred to as <i>block</i> in the APIs and
+  reports &ndash; represents a consecutive sequence of byte code instructions
+  and is a unit that will either execute completely or not all. The single
+  exception from this definition occurs when the java exception mechanism comes
+  to action (i.e. a java exception "flies"). This always interrupts the current
+  blocks execution. The boundaries between blocks are
 </p>
 
 <ul>
@@ -43,15 +46,15 @@
 
 <p>
   The JaCoCo instrumentation mechanism inserts a probe at the end of every
-  block. When the probe gets executes the block can be considered as executed.
-  Unfortunately the opposite does not hold true: Exceptions might interrupt a
-  block somewhere in the middle and the probe will not get executed. This
-  results in the major drawback of basic block based probes:
+  block. When the probe gets executed the block is considered executed.
+  This results in the major drawback of basic block based probes:
 </p>
 
 <p class="hint">
-  Blocks that encounter an exception somewhere in the middle will be considered
-  as not executed.  
+  Blocks that encounter an exception somewhere in the middle of their execution
+  will be considered as not executed. This is correct as the block actually
+  didn't get executed but JaCoCo won't be able to tell which lines of the block
+  executed and which didn't.  
 </p>
 
 <p>
@@ -71,8 +74,8 @@
 <p>
   For each block the number of included byte code instructions can be easily
   determined. The instruction counter summarizes the number of single byte code
-  instructions that belong to executed blocks. As blocks may have different
-  lengths instructions represent the size of the blocks and can serve as a
+  instructions that belong to executed blocks. As blocks may be of different
+  length, instructions give a good measure of block size and can serve as a
   replacement when no line information is available. 
 </p>
 
@@ -80,10 +83,10 @@
 
 <p>
   For all class files that have been compiled in debug mode with source line
-  information, coverage information for individual lines can be calculated from
+  information, coverage information for individual lines can be derived from
   basic blocks. Each block may span one ore multiple lines of source code. On
-  the other hand a single line of source my belong to multiple blocks. A source
-  line is considered as executed when at least one block that includes this line
+  the other hand a single line of source may belong to multiple blocks. A source
+  line is considered executed when at least one block that includes this line
   has been executed.
 </p>
 
@@ -91,7 +94,7 @@
   Due to the fact that a single line may belong to more that one block 
   <i>partial</i> coverage can happen if some of the blocks are executed while
   others are not. This is typically the case with boolean expressions. While
-  partially coverage lines are counted as executed due to the definition in the
+  partially covered lines are seen as executed due to the definition in the
   previous paragraph, they are highlighted in yellow color in the coverage
   reports. 
 </p>
@@ -103,14 +106,14 @@
   considered as executed when at least one block has been executed. As JaCoCo
   works on byte code level also constructors and static initializers are counted
   as methods. Some of these methods may not have a direct correspondence in Java
-  source code, like implicitly generated default constructors or initializers
+  source code, like implicit and thus generated default constructors or initializers
   for constants.
 </p>
 
 <h2>Classes</h2>
 
 <p>
-  A class is considered as executed when at least one of its method has been
+  A class is considered as executed when at least one of its methods has been
   executed. Note that JaCoCo considers constructors as well as static
   initializers as methods. As Java interface types may contain static
   initializers such interfaces are also considered as executable classes.
diff --git a/org.jacoco.doc/docroot/doc/implementation.html b/org.jacoco.doc/docroot/doc/implementation.html
index 8be12f6..93f9ee0 100644
--- a/org.jacoco.doc/docroot/doc/implementation.html
+++ b/org.jacoco.doc/docroot/doc/implementation.html
@@ -81,12 +81,11 @@
 </p>
 
 <p>
-  The Java agent hook requires at least 1.5 JVMs. For reporting class files
-  compiled with debug information (line numbers) allow a good mapping back to
-  source level. Although some Java language constructs are compiled in a way
-  that the the coverage highlighting leads to unexpected results, especially
-  in case of implicitly generated code like default constructors or control
-  structures for finally statements.
+  The Java agent hook requires at least 1.5 JVMs. Class files compiled with
+  debug information (line numbers) allow for source code highlighting. Unluckily
+  some Java language constructs get compiled to byte code that produces
+  unexpected highlighting results, especially in case of implicitly generated
+  code like default constructors or control structures for finally statements.
 </p>
 
 
@@ -102,39 +101,40 @@
 <p>
   A basic block is a piece of byte code that has a single entry point (the first
   byte code instruction) and a single exit point (like <code>jump</code>,
-  <code>throw</code> or <code>return</code>). A basic code must not contain jump
+  <code>throw</code> or <code>return</code>). A basic block must not contain jump
   targets except the entry point. One can think of basic blocks as the nodes in
   a control flow graph of a method. Using basic block boundaries to insert code
-  coverage probes has been very successfully proven by 
+  coverage probes has been very successfully utilized by 
   <a href="http://emma.sourceforge.net/">EMMA</a>.
 </p>
 
 <p>
-  Basic block instrumentation works regardless whether the class files have been
+  Basic block instrumentation works regardless of whether the class files have been
   compiled with debug information for source lines. Source code highlighting
   will of course not be possible without this debug information, but percentages
   on method level can still be calculated. Basic block probes result in
-  reasonable overhead regarding class file size and execution overhead. As e.g.
-  multi-condition statements form several basic blocks partial line coverage is
-  possible. Calculating basic block relies on the Java byte code only, therefore
+  reasonable overhead regarding class file size and performance. Partial line
+  coverage can occur if a line contains more than one statement or a statement
+  gets compiled into byte code forming more than one basic block (e.g. boolean
+  assignments). Calculating basic block relies on the Java byte code only, therefore
   JaCoCo is independent of the source language and should also work with other
   Java VM based languages like <a href="http://www.scala-lang.org/">Scala</a>.
 </p>
 
 <p>
-  The huge drawback of this approach is that fact, that basic blocks are
+  The huge drawback of this approach is the fact that basic blocks are
   actually much smaller in the Java VM: Nearly every byte code instruction
   (especially method invocations) can result in an exception. In this case the
   block is left somewhere in the middle without hitting the probe, which leads
   to unexpected results for example in case of negative tests. A possible
-  solutions would be to add exception handlers that trigger special probes.     
+  solution would be to add exception handlers that trigger special probes.     
 </p>
 
 <h2>Coverage Agent Isolation</h2>
 
 <p class="intro">
   The Java agent is loaded by the application class loader. Therefore the
-  classes of the agent live in the same name space than the application classes
+  classes of the agent live in the same name space like the application classes
   which can result in clashes especially with the third party library ASM. The
   JoCoCo build therefore moves all agent classes into a unique package.  
 </p>
@@ -157,9 +157,9 @@
 
 <p>
   The Java agent mechanism used for on-the-fly instrumentation became available
-  with in Java 1.5 VMs. Coding and testing with Java 1.5 language level is more
-  efficient, less error-prone &ndash; and more fun. JaCoCo will still allow to
-  run against Java code compiled for older versions.
+  with Java 1.5 VMs. Coding and testing with Java 1.5 language level is more
+  efficient, less error-prone &ndash; and more fun than with older versions.
+  JaCoCo will still allow to run against Java code compiled for these.
 </p>
 
 
@@ -167,11 +167,11 @@
 
 <p class="intro">
   Instrumentation requires mechanisms to modify and generate Java byte code.
-  JaCoCo uses the ASM library for this purpose.
+  JaCoCo uses the ASM library for this purpose internally.
 </p>
 
 <p>
-  Implementing the Java byte code specification would be a extensive and
+  Implementing the Java byte code specification would be an extensive and
   error-prone task. Therefore an existing library should be used. The
   <a href="http://asm.objectweb.org/">ASM</a> library is lightweight, easy to
   use and very efficient in terms of memory and CPU usage. It is actively
@@ -193,8 +193,8 @@
   deployment scenarios the actual version of the test target might be different
   from current development version. A code coverage report should guarantee that
   the presented figures are extracted from a valid test target. A hash code of
-  the class definitions allows a differentiate between classes and versions of a
-  class. The CRC64 hash computation is simple and fast resulting in a small 64
+  the class definitions allows to differentiate between classes and versions of
+  classes. The CRC64 hash computation is simple and fast resulting in a small 64
   bit identifier. 
 </p>
 
@@ -205,7 +205,7 @@
   instrumentation based technologies (e.g. AspectJ). In this case the hash code
   will change and identity gets lost. On the other hand code coverage analysis
   based on classes that have been somehow altered will produce unexpected
-  results. The CRC64 has code might produce so called <i>collisions</i>, i.e.
+  results. The CRC64 code might produce so called <i>collisions</i>, i.e.
   creating the same hash code for two different classes. Although CRC64 is not
   cryptographically strong and collision examples can be easily computed, for
   regular class files the collision probability is very low. 
@@ -221,7 +221,7 @@
 
 <p>
   Making a runtime library available to all instrumented classes can be a
-  painful or impossible task in frameworks that use there own class loading
+  painful or impossible task in frameworks that use their own class loading
   mechanisms. Therefore JaCoCo decouples the instrumented classes and the
   coverage runtime through official JRE API types. Currently two approaches have
   been implemented:
@@ -253,8 +253,7 @@
   The complete data tree of a huge coverage report is too big to fit into a
   reasonable heap memory configuration. Therefore the coverage analysis and
   report generation is implemented as "depth first" traversals. Which means that
-  at any point in time only only the following data has to be held in main
-  memory:  
+  at any point in time only the following data has to be held in working memory:  
 </p>
 
 <ul>
@@ -275,7 +274,7 @@
   Using VM identifiers directly does not cause any transformation overhead at
   runtime. There are several programming languages based on the Java VM that
   might use different notations. Specific transformations should therefore only
-  happen at the user interface level, for example while report generation.
+  happen at the user interface level, for example during report generation.
 </p>
 
 <h2>Modularization of the JaCoCo implementation</h2>
@@ -283,13 +282,13 @@
 <p class="intro">
   JaCoCo is implemented in several modules providing different functionality.
   These modules are provided as OSGi bundles with proper manifest files. But
-  there is no dependencies on OSGi itself.
+  there are no dependencies on OSGi itself.
 </p>
 
 <p>
-  Using OSGi bundles allows well defines dependencies at development time and
+  Using OSGi bundles allows well defined dependencies at development time and
   at runtime in OSGi containers. As there are no dependencies on OSGi, the
-  bundles can also be used as regular JAR files.  
+  bundles can also be used like regular JAR files.  
 </p>
 
 <div class="footer">
diff --git a/org.jacoco.doc/docroot/doc/mission.html b/org.jacoco.doc/docroot/doc/mission.html
index 73c4352..7380fc1 100644
--- a/org.jacoco.doc/docroot/doc/mission.html
+++ b/org.jacoco.doc/docroot/doc/mission.html
@@ -24,10 +24,10 @@
 </p>
 
 <p>
-  There are several open source coverage technologies for Java. While
+  There are several open source coverage technologies for Java available. While
   implementing the Eclipse plug-in <a href="http://www.eclemma.org/">EclEmma</a>
   the observation was that none of them are really designed for integration.
-  Most of them are build for a particular tool (Ant tasks, command line, IDE
+  Most of them are specifically fit to a particular tool (Ant tasks, command line, IDE
   plug-in) and do not offer a documented API that allows embedding in different
   contexts. One of the best and widely used available open source tools is
   <a href="http://emma.sourceforge.net/">EMMA</a>. While EclEmma is based on it
diff --git a/org.jacoco.doc/docroot/index.html b/org.jacoco.doc/docroot/index.html
index 4eee0b7..f05fded 100644
--- a/org.jacoco.doc/docroot/index.html
+++ b/org.jacoco.doc/docroot/index.html
@@ -36,8 +36,8 @@
 
 <p class="hint">
   Due to the prototype status future versions will come with additional or
-  modified features and may show different behavior in certain situations. The
-  Java API is not frozen yet.
+  modified features and may show different behavior in various situations. The
+  Java API is certainly not frozen yet.
 </p>
 
 <h2>Contents</h2>