diff --git a/documentation/current/method/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki b/documentation/current/method/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki
index 9e4ddcad..1773f6e1 100644
--- a/documentation/current/method/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki
+++ b/documentation/current/method/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki
@@ -4,18 +4,22 @@
 [[Image:OOSC2 small|OOSC2]]
 
 
-'''''Object-Oriented Software Construction, 2nd Edition''''' by Bertrand Meyer.
+=='''''Object-Oriented Software Construction, 2nd Edition''''' by Bertrand Meyer.==
 
 Prentice Hall Professional Technical Reference.
 
 1254 + xxviii pp.
+
 Soft cover.
-ISBN 0-13-629155-4
+
+<nowiki>ISBN 0-13-629155-4</nowiki>
 
 
-This Jolt Award winner takes the reader through the clear, logical, and comprehensive formation of a method for object-oriented software development. During this journey, Meyer also evolves a notation capable of expressing the products of each phase of development. This notation is Eiffel the language.
+This Jolt Award winner takes the reader through the clear, logical, and comprehensive formation of a method for object-oriented software development ... the Eiffel method. During this journey, the author evolves a notation capable of expressing the products of each phase of development, from analysis through implementation. This notation is Eiffel the language.
 
 
+==Praise for '''''Object-Oriented Software Construction, 2nd Edition'''''==
+
 Roger Smith, on the Dr. Dobbs Journal website, writes:
 
 :"In my unbiased opinion [...] it is destined to become the comprehensive and definitive reference for most methodological and technical questions raised by object technology. Its width and breadth of scope is impressive, from object-oriented techniques like Design by Contract and inheritance, to methodology issues like patterns and class design, to advanced issues like concurrency and persistence."
@@ -27,3 +31,5 @@ In ''Unix Review'', Stan Kelly-Bootle calls this book "The ultimate O-O guide."
 Ian Graham, in ''Journal of Object-Oriented Programming'' calls it "Epoch-making".
 
 
+
+
diff --git a/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki b/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki
index 0e1fc12e..0352448e 100644
--- a/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki
+++ b/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki
@@ -156,7 +156,7 @@ Here attribute declarations for <code>my_nvp</code> and <code>my_nvp_list</code>
 In a second case, there is also an Initialization rule violation (VEVI), this time on <code>Result</code>, in this routine:
 
 <code>
-    at_first (nm: STRING): NVP is
+    at_first (nm: STRING): NVP
             -- The first found NVP with name matching nm.
             -- 	Or Void if not found
         require
@@ -181,7 +181,7 @@ Here we cannot just ensure that <code>Result</code> is always attached, because,
 So the least impact to this routine will be to declare its type as <code>detachable</code>:
 
 <code>
-    at_first (nm: STRING): detachable NVP is
+    at_first (nm: STRING): detachable NVP
             -- The first found NVP with name matching nm.
             -- 	Or Void if not found
 </code>
@@ -205,7 +205,7 @@ The change to <code>at_first</code> satisfies the VEVI issue in <code>at_first</
 <code>value_at_first</code> looks like this:
 
 <code>
-    value_at_first (nm: STRING): detachable STRING is
+    value_at_first (nm: STRING): detachable STRING
             -- Value from first found NVP with name matching nm
             -- 	Or Void of not found
         require
@@ -228,7 +228,7 @@ The problem is that the local variable <code>tn</code> is declared as <code>atta
 Here the '''attached syntax''' can fix the problem and streamline the routine:
 
 <code>
-    value_at_first (nm: STRING): detachable STRING is
+    value_at_first (nm: STRING): detachable STRING
             -- Value from first found NVP with name matching nm
             -- 	Or Void of not found
         require
diff --git a/documentation/current/papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki b/documentation/current/papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki
index 02c379f2..2ea5ce86 100644
--- a/documentation/current/papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki
+++ b/documentation/current/papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki
@@ -2,7 +2,7 @@
 [[Property:link_title|Void-safety: how Eiffel removes null-pointer dereferencing]]
 [[Property:weight|0]]
 [[Property:uuid|d9380464-4312-b76e-9bfd-e57df0f59b4a]]
-This white paper (see "Attachment" link below) presents the Eiffel void safety mechanism, fully implemented in EiffelStudio 6.4.
+This white paper (see [[file:void-safe-eiffel.pdf|"Attachment" link ]] below) presents the Eiffel void safety mechanism, fully implemented in EiffelStudio 6.4.
 
 In almost every program running today there is a ticking time bomb: the risk of a "void call". A void call is possible in programs written in almost any programming language; its effect is usually to crash the program. Many unexplained program failures and other abnormal behaviors result from void calls.