Updated bug
diff --git a/examples/org.eclipse.graphiti.doc/resources/docu/whats-new.html b/examples/org.eclipse.graphiti.doc/resources/docu/whats-new.html
index 63fbc59..2bb2e28 100644
--- a/examples/org.eclipse.graphiti.doc/resources/docu/whats-new.html
+++ b/examples/org.eclipse.graphiti.doc/resources/docu/whats-new.html
@@ -46,7 +46,7 @@
 		context in IDirectEditing APIs</b></td>
 		<td width="70%" valign="top">So far the direct editing
 		functionality in Graphiti was purely String-based. Entries in the drop
-		down or for code completion could only be indentified by the String
+		down or for code completion could only be identified by the String
 		they were also represented in the UI to the user. Now it is possible
 		to define and provide a proposal support class based on the new
 		interface <i>IProposalSupport</i> based on additional information, e.g
@@ -65,7 +65,7 @@
 	<tr id="bug 340708">
 		<td width="30%" valign="top" align="left"><b>Double click for
 		connections</b></td>
-		<td width="70%" valign="top">It is now possible to register a
+		<td width="70%" valign="top">It is now possible to register A
 		feature that will be executed on double click on a connection. This
 		was so far only possible for shapes.</td>
 	</tr>
@@ -112,7 +112,7 @@
 		other shape. As a tool builder you need to allow this new behavior
 		when the user tries to drop a connection either via a <i>CreateConnectionFeature</i>
 		or a <i>ReconnectConnectionFeature</i>. Example implementations are
-		available in the Sketch testtool in the examples folder in the
+		available in the Sketch testtool in the tests folder in the
 		Graphiti CVS. <img src="images/NaNW-Indigo-M6-Connection.jpg" /></td>
 	</tr>
 	<tr>
@@ -135,8 +135,8 @@
 		that were created using Graphiti versions before 0.8.0 M6 will need a
 		migration</b> if tool defined fonts are used. The Graphiti framework
 		provides a small migration utility that can be triggered at an
-		appropriate time by the tool. We decided explictly against triggering
-		the migration from the framework, because there will definatly by
+		appropriate time by the tool. We decided explicitly against triggering
+		the migration from the framework, because there will definitely by
 		different requirements on the time of triggering in the various tool
 		scenarios. Besides there will be tools that will need no migration at
 		all and would be only suffer a time penalty from that check and
@@ -180,7 +180,7 @@
 		integration of delete, remove and direct editing features. These
 		functionalities before had to be implemented within separate features.
 		Besides the patterns now easily allow to prevent that a creation tool
-		entry in created for them in the editor palette.</td>
+		entry is created for them in the editor palette.</td>
 	</tr>
 	<tr>
 		<td colspan="2">