Fixed RADME.md layout

1 files changed, 56 insertions, 56 deletions

diff --git a/README.md b/README.md
index 1dbe133..049f5e2 100644
--- a/README.md
+++ b/README.md
@@ -5,35 +5,35 @@ uSCXML is a SCXML interpreter written in C/C++. It is mostly feature-complete an
 It runs on <b>Linux</b>, <b>Windows</b> and <b>MacOSX</b>, each 32- as well as 64Bits as well as <b>iOS</b>.
 There are still a few rough edges though, especially with the plugins and custom extensions.
 
-   * <b>Datamodels</b>
-      * Full [ECMAScript datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/ecmascript) using Google's v8 (and JavaScriptCore on MacOSX and iOS)
-         * Simplified support for [Web Storage](http://www.w3.org/TR/2013/REC-webstorage-20130730/) in document.localStorage
-         * Support for binary data via [TypedArrays](https://www.khronos.org/registry/typedarray/specs/latest/) (will not throw exceptions yet)
-      * Full [NULL datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/null) with required <tt>In</tt> predicate
-      * Early [Prolog datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/prolog/swi) using SWI prolog
-      * Rudimentary support for [XPath datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/xpath)
-   * <b>Invokers</b>
-      * <tt>scxml</tt>: Invoke a nested scxml interpreter
-      * <tt>dirmon</tt>: Watches a directory for changes to files
-      * <tt>scenegraph</tt>: Simplified 3D scenegraphs with custom markup
-      * <tt>heartbeat</tt>: Periodically sends events
-      * <tt>umundo</tt>: Subscribe to channels and publish events
-   * <b>DOM</b>
-      * DOM Core Level 2 + XPath extensions available for ecmascript datamodel
-      * Namespace aware to embed custom markup for special invokers
-   * <b>Communication</b>
-      * Features the standard basichttp io-processor
-      * Features the required SCXML io-processor
-      * <b>No</b> DOM io-processor
-      * Can actually respond to HTTP requests with data via &lt;response>
-   * <b>Language Bindings</b>
-      * PHP module for apache and cli interpreter
+* <b>Datamodels</b>
+    * Full [ECMAScript datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/ecmascript) using Google's v8 (and JavaScriptCore on MacOSX and iOS)
+        * Simplified support for [Web Storage](http://www.w3.org/TR/2013/REC-webstorage-20130730/) in document.localStorage
+        * Support for binary data via [TypedArrays](https://www.khronos.org/registry/typedarray/specs/latest/) (will not throw exceptions yet)
+    * Full [NULL datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/null) with required <tt>In</tt> predicate
+    * Early [Prolog datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/prolog/swi) using SWI prolog
+    * Rudimentary support for [XPath datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/xpath)
+* <b>Invokers</b>
+    * <tt>scxml</tt>: Invoke a nested scxml interpreter
+    * <tt>dirmon</tt>: Watches a directory for changes to files
+    * <tt>scenegraph</tt>: Simplified 3D scenegraphs with custom markup
+    * <tt>heartbeat</tt>: Periodically sends events
+    * <tt>umundo</tt>: Subscribe to channels and publish events
+* <b>DOM</b>
+    * DOM Core Level 2 + XPath extensions available for ecmascript datamodel
+    * Namespace aware to embed custom markup for special invokers
+* <b>Communication</b>
+    * Features the standard basichttp io-processor
+    * Features the required SCXML io-processor
+    * <b>No</b> DOM io-processor
+    * Can actually respond to HTTP requests with data via &lt;response>
+* <b>Language Bindings</b>
+    * PHP module for apache and cli interpreter
 
 ## Test Reports
 
- * We continuously run the [W3C IRP tests](http://www.w3.org/Voice/2013/scxml-irp/) for SCXML. 
- * Have a look at the [result](http://uscxml.tk.informatik.tu-darmstadt.de/cdash/index.php?project=uscxml) for the various platforms.
- * The manual and XPath specific tests are [excluded](https://github.com/tklab-tud/uscxml/blob/master/contrib/ctest/CTestCustom.ctest.in).
+* We continuously run the [W3C IRP tests](http://www.w3.org/Voice/2013/scxml-irp/) for SCXML. 
+* Have a look at the [result](http://uscxml.tk.informatik.tu-darmstadt.de/cdash/index.php?project=uscxml) for the various platforms.
+* The manual and XPath specific tests are [excluded](https://github.com/tklab-tud/uscxml/blob/master/contrib/ctest/CTestCustom.ctest.in).
 
 uSCXML still fails the following ecmascript tests:
 
@@ -89,44 +89,44 @@ In order to use the interpreter, you need to <tt>#include "uscxml/Interpreter.h"
 objects of <tt>uscxml::Interpreter</tt>.
 
 ### Non-Blocking Interpretation with SCXML from URL
-    	Interpreter scxml = Interpreter::fromURL("http://www.example.com/fancy.scxml");
-    	scxml.start(); // non-blocking
+    Interpreter scxml = Interpreter::fromURL("http://www.example.com/fancy.scxml");
+    scxml.start(); // non-blocking
 
 There are some cases, i.e. with graphical invokers, where the main thread is <emph>required</emph> in order
 to react to UI events. You will have to deligate control flow from the main thread into the interpreter
 every now and then:
 
-    	interpreter.runOnMainThread(25);
+    interpreter.runOnMainThread(25);
 
 This will perform a single iteration on the invoked components with a maximum of 25 frames per seconds 
 or return immediately. You will have to call this method every now and then if you are using e.g. the
 <tt>scenegraph</tt> invoker.
 
 ### Blocking Interpretation with inline SCXML
-    	Interpreter scxml = Interpreter::fromXML("<scxml><final id="exit"/></scxml>");
-    	scxml.interpret(); // blocking
+    Interpreter scxml = Interpreter::fromXML("<scxml><final id="exit"/></scxml>");
+    scxml.interpret(); // blocking
 
 ### Callbacks for an Interpreter
 
 You can register an <tt>InterpreterMonitor</tt> prior to start in order to receive
 control-flow upon various events in the Interpreter.
 
-    	class StatusMonitor : public uscxml::InterpreterMonitor {
-    		void onStableConfiguration(Interpreter) {}
-    		void beforeCompletion(Interpreter) {}
-    		void afterCompletion(Interpreter) {}
-    		void beforeMicroStep(Interpreter) {}
-    		void beforeTakingTransitions(Interpreter, const Arabica::XPath::NodeSet<std::string>&) {}
-    		void beforeEnteringStates(Interpreter, const Arabica::XPath::NodeSet<std::string>&) {}
-    		void afterEnteringStates(Interpreter) {}
-    		void beforeExitingStates(Interpreter, const Arabica::XPath::NodeSet<std::string>&) {}
-    		void afterExitingStates(Interpreter) {}
-    	};
-
-    	StatusMonitor statMon;
-    	Interpreter scxml = Interpreter::fromXML("<scxml><final id="exit"/></scxml>");
-    	scxml.addMonitor(&statMon);
-    	scxml.start();
+    class StatusMonitor : public uscxml::InterpreterMonitor {
+    	void onStableConfiguration(Interpreter) {}
+    	void beforeCompletion(Interpreter) {}
+    	void afterCompletion(Interpreter) {}
+    	void beforeMicroStep(Interpreter) {}
+    	void beforeTakingTransitions(Interpreter, const Arabica::XPath::NodeSet<std::string>&) {}
+    	void beforeEnteringStates(Interpreter, const Arabica::XPath::NodeSet<std::string>&) {}
+    	void afterEnteringStates(Interpreter) {}
+    	void beforeExitingStates(Interpreter, const Arabica::XPath::NodeSet<std::string>&) {}
+    	void afterExitingStates(Interpreter) {}
+    };
+
+    StatusMonitor statMon;
+    Interpreter scxml = Interpreter::fromXML("<scxml><final id="exit"/></scxml>");
+    scxml.addMonitor(&statMon);
+    scxml.start();
 
 This will cause the interpreter to invoke the callbacks from the monitor whenever the corresponding
 internal phase is reached.
@@ -135,15 +135,15 @@ internal phase is reached.
 
 The uSCXML interpreter can be extended by introducing new
 
-   1. DataModels as embedded scripting languages (e.g. ECMAScript, Prolog and XPath)
-   2. Invokers to represent external components that deliver and accept events (e.g. iCal, SceneGraph, DirectoryMonitor)
-   3. I/O-Processors to provide communication with external systems (e.g. BasicHTTP, SCXML).
-   4. Elements for Executable Content (e.g. &lt;respond>, &lt;fetch>, &lt;postpone>).
+1. DataModels as embedded scripting languages (e.g. ECMAScript, Prolog and XPath)
+2. Invokers to represent external components that deliver and accept events (e.g. iCal, SceneGraph, DirectoryMonitor)
+3. I/O-Processors to provide communication with external systems (e.g. BasicHTTP, SCXML).
+4. Elements for Executable Content (e.g. &lt;respond>, &lt;fetch>, &lt;postpone>).
 
 The basic approach to extend the interpreter is the same in all cases:
 
-   1. Write a class inheriting the abstract base class (e.g. <tt>DataModelImpl</tt>, <tt>InvokerImpl</tt>, <tt>IOProcessorImpl</tt>, <tt>ExecutableContentImpl</tt>).
-   2. Instantiate your class and register it as a prototype at the <tt>Factory</tt> via one of its static <tt>register*</tt> methods.
-      1. You can register at the global Factory Singleton via <tt>Factory::register*(prototypeInstance)</tt>
-      2. Or provide a new Factory instance to selected interpreters as an in-between.
-   3. Write an interpreter using your new functionality.
+1. Write a class inheriting the abstract base class (e.g. <tt>DataModelImpl</tt>, <tt>InvokerImpl</tt>, <tt>IOProcessorImpl</tt>, <tt>ExecutableContentImpl</tt>).
+2. Instantiate your class and register it as a prototype at the <tt>Factory</tt> via one of its static <tt>register*</tt> methods.
+    1. You can register at the global Factory Singleton via <tt>Factory::register*(prototypeInstance)</tt>
+    2. Or provide a new Factory instance to selected interpreters as an in-between.
+3. Write an interpreter using your new functionality.