version 2.0.0
diff --git a/doc/html_generated/testcases.html b/doc/html_generated/testcases.html
index b6605e6..267bc6e 100644
--- a/doc/html_generated/testcases.html
+++ b/doc/html_generated/testcases.html
@@ -5,9 +5,7 @@
 
 ## Test cases
 
-While **doctest** fully supports the traditional, xUnit, style of class-based fixtures containing test case methods this is not the preferred style.
-
-Instead **doctest** provides a powerful mechanism for nesting subcases within a test case. For a more detailed discussion see the [**tutorial**](tutorial.html#test-cases-and-subcases).
+While **doctest** fully supports the traditional, xUnit, style of class-based fixtures containing test case methods this is not the preferred style. Instead **doctest** provides a powerful mechanism for nesting subcases within a test case. For a more detailed discussion see the [**tutorial**](tutorial.html#test-cases-and-subcases).
 
 Test cases and subcases are very easy to use in practice:
 
@@ -16,6 +14,8 @@
 
 _test name_ and _subcase name_ are free form, quoted, strings. Test names don't have to be unique within the **doctest** executable. They should also be string literals.
 
+Keep in mind that even though **doctest** is [**thread-safe**](faq.html#is-doctest-thread-aware) - using subcases has to be done only in the main test runner thread.
+
 For examples see the [Tutorial](tutorial.html)
 
 Test cases can also be parameterized - see the [documentation](parameterized-tests.html)
@@ -59,27 +59,26 @@
 
 ```
 class UniqueTestsFixture {
-  private:
-   static int uniqueID;
-  protected:
-   DBConnection conn;
-  public:
-   UniqueTestsFixture() : conn(DBConnection::createConnection("myDB")) {
-   }
-  protected:
-   int getID() {
-     return ++uniqueID;
-   }
- };
+private:
+    static int uniqueID;
+protected:
+    DBConnection conn;
+public:
+    UniqueTestsFixture() : conn(DBConnection::createConnection("myDB")) {}
+protected:
+    int getID() {
+        return ++uniqueID;
+    }
+};
 
- int UniqueTestsFixture::uniqueID = 0;
+int UniqueTestsFixture::uniqueID = 0;
 
- TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/No Name") {
-   REQUIRE_THROWS(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), ""));
- }
- TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/Normal") {
-   REQUIRE(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), "Joe Bloggs"));
- }
+TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/No Name") {
+    REQUIRE_THROWS(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), ""));
+}
+TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/Normal") {
+    REQUIRE(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), "Joe Bloggs"));
+}
 ```
 
 The two test cases here will create uniquely-named derived classes of UniqueTestsFixture and thus can access the `getID()` protected method and `conn` member variables. This ensures that both the test cases are able to create a DBConnection using the same method (DRY principle) and that any ID's created are unique such that the order that tests are executed does not matter.
@@ -171,6 +170,8 @@
 
 [Home](readme.html#reference)
 
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
 
 </xmp>
 <script src="strapdown.js/strapdown.js"></script>