Final changes, report is handed-in.

docs/data/diagrams.tex

@@ -311,8 +311,8 @@
         \architecture{
             \tikzstyle{area} = [block, fill=gray!15];
             \tikzstyle{tracker} = [block, draw=gray!50, text width=7em];
-            \tikzstyle{left} = [xshift=-5em];
-            \tikzstyle{right} = [xshift=5em];
+            \tikzstyle{leftchild} = [xshift=-5em];
+            \tikzstyle{rightchild} = [xshift=5em];
 
             \node[block, below of=driver] (eventdriver) {Event driver}
                 edge[linefrom] node[right, near end] {device-specific messages} (driver);
@@ -320,7 +320,7 @@
             \node[area, below of=eventdriver] (rootarea) {Screen area}
                 edge[linefrom] (eventdriver);
 
-            \node[area, below of=rootarea, left] (appwindow) {Application window area}
+            \node[area, below of=rootarea, leftchild] (appwindow) {Application window area}
                 edge[lineto, <->] (rootarea);
             \node[tracker, left of=appwindow, xshift=-4em, yshift=3em] {Transformation tracker}
                 edge[linefrom, bend right=10] (appwindow)
@@ -329,13 +329,13 @@
                 edge[lineto, dotted, bend right=10] (appwindow)
                 edge[linefrom, bend left=10] (appwindow);
 
-            \node[area, below of=rootarea, right] (overlay) {Overlay area}
+            \node[area, below of=rootarea, rightchild] (overlay) {Overlay area}
                 edge[lineto, <->] (rootarea);
             \node[tracker, right of=overlay, xshift=4em] (tracker) {Hand tracker}
                 edge[lineto, dotted, bend left=10] (overlay)
                 edge[linefrom, bend right=10] (overlay);
 
-            \node[area, below of=appwindow, left] (rectangle) {Rectangle area}
+            \node[area, below of=appwindow, leftchild] (rectangle) {Rectangle area}
                 edge[lineto, <->] (appwindow);
             \node[tracker, left of=rectangle, xshift=-4em, yshift=2em] (recttracker) {Transformation tracker}
                 edge[lineto, dotted, bend left=10] (rectangle)
@@ -344,7 +344,7 @@
                 edge[lineto, dotted, bend right=10] (rectangle)
                 edge[linefrom, bend left=10] (rectangle);
 
-            \node[area, below of=appwindow, right] (triangle) {Triangle area}
+            \node[area, below of=appwindow, rightchild] (triangle) {Triangle area}
                 edge[lineto, <->] (appwindow);
             \node[tracker, right of=triangle, xshift=4em, yshift=2em] {Transformation tracker}
                 edge[lineto, dotted, bend right=10] (triangle)

docs/report.tex

@@ -519,6 +519,12 @@ events.
 
 The following component implementations are included in the implementation:
 
+\textbf{Event drivers}
+\begin{itemize}
+    \item TUIO driver, using only the support for simple touch points with an
+        $(x, y)$ position.
+\end{itemize}
+
 \textbf{Event areas}
 \begin{itemize}
     \item Circular area
@@ -534,11 +540,8 @@ The following component implementations are included in the implementation:
     \item Transformation tracker, supports $rotate,~pinch,~drag,~flick$ gestures.
 \end{itemize}
 
-\textbf{Event drivers}
-\begin{itemize}
-    \item TUIO driver, using only the support for simple touch points with an
-        $(x, y)$ position.
-\end{itemize}
+The implementation of the TUIO event driver is described in section
+\ref{sec:tuio}.
 
 The reference implementation also contains some geometric functions that are
 used by several event area implementations. The event area implementations are
@@ -548,9 +551,58 @@ All gesture trackers have been implemented using an imperative programming
 style. Section \ref{sec:tracker-registration} shows how gesture trackers can be
 added to the architecture. Sections \ref{sec:basictracker} to
 \ref{sec:transformationtracker} describe the gesture tracker implementations in
-detail. The implementation of the TUIO event driver is described in section
-\ref{sec:tuio}.
+detail.
+
+\section{The TUIO event driver}
+\label{sec:tuio}
+
+The TUIO protocol \cite{TUIO} defines a way to geometrically describe tangible
+objects, such as fingers or objects on a multi-touch table. Object information
+is sent to the TUIO UDP port (3333 by default). For efficiency reasons, the
+TUIO protocol is encoded using the Open Sound Control \cite[OSC]{OSC} format.
+An OSC server/client implementation is available for Python: pyOSC
+\cite{pyOSC}.
+
+A Python implementation of the TUIO protocol also exists: pyTUIO \cite{pyTUIO}.
+However, a bug causes the execution of an example script to yield an error in
+Python's built-in \texttt{socket} library. Therefore, the TUIO event driver
+receives TUIO messages at a lower level, using the pyOSC package to receive
+TUIO messages.
+
+The two most important message types of the protocol are ALIVE and SET
+messages. An ALIVE message contains the list of ``session'' id's that are
+currently ``active'', which in the case of multi-touch a table means that they
+are touching the touch surface. A SET message provides geometric information of
+a session, such as position, velocity and acceleration. Each session represents
+an object touching the touch surface. The only type of objects on the
+multi-touch table are what the TUIO protocol calls ``2DCur'', which is a (x, y)
+position on the touch surface.
+
+ALIVE messages can be used to determine when an object touches and releases the
+screen. E.g. if a session id was in the previous message but not in the
+current, the object it represents has been lifted from the screen. SET messages
+provide information about movement. In the case of simple (x, y) positions,
+only the movement vector of the position itself can be calculated. For more
+complex objects such as fiducials, arguments like rotational position and
+acceleration are also included. ALIVE and SET messages are combined to create
+\emph{point\_down}, \emph{point\_move} and \emph{point\_up} events by the TUIO
+event driver.
+
+TUIO coordinates range from $0.0$ to $1.0$, with $(0.0, 0.0)$ being the left
+top corner of the touch surface and $(1.0, 1.0)$ the right bottom corner. The
+TUIO event driver scales these to pixel coordinates so that event area
+implementations can use pixel coordinates to determine whether an event is
+located within them. This transformation is also mentioned by the online
+TUIO specification \cite{TUIO_specification}:
 
+\begin{quote}
+    In order to compute the X and Y coordinates for the 2D profiles a TUIO
+    tracker implementation needs to divide these values by the actual sensor
+    dimension, while a TUIO client implementation consequently can scale these
+    values back to the actual screen dimension.
+\end{quote}
+
+\newpage
 \section{Gesture tracker registration}
 \label{sec:tracker-registration}
 
@@ -657,55 +709,6 @@ The angle used for the \emph{rotate} gesture is only divided by the number of
 touch points to obtain an average rotation of all touch points:
 $$rotate.angle = \frac{\alpha}{N}$$
 
-\section{The TUIO event driver}
-\label{sec:tuio}
-
-The TUIO protocol \cite{TUIO} defines a way to geometrically describe tangible
-objects, such as fingers or objects on a multi-touch table. Object information
-is sent to the TUIO UDP port (3333 by default). For efficiency reasons, the
-TUIO protocol is encoded using the Open Sound Control \cite[OSC]{OSC} format.
-An OSC server/client implementation is available for Python: pyOSC
-\cite{pyOSC}.
-
-A Python implementation of the TUIO protocol also exists: pyTUIO \cite{pyTUIO}.
-However, a bug causes the execution of an example script to yield an error in
-Python's built-in \texttt{socket} library. Therefore, the TUIO event driver
-receives TUIO messages at a lower level, using the pyOSC package to receive
-TUIO messages.
-
-The two most important message types of the protocol are ALIVE and SET
-messages. An ALIVE message contains the list of ``session'' id's that are
-currently ``active'', which in the case of multi-touch a table means that they
-are touching the touch surface. A SET message provides geometric information of
-a session, such as position, velocity and acceleration. Each session represents
-an object touching the touch surface. The only type of objects on the
-multi-touch table are what the TUIO protocol calls ``2DCur'', which is a (x, y)
-position on the touch surface.
-
-ALIVE messages can be used to determine when an object touches and releases the
-screen. E.g. if a session id was in the previous message but not in the
-current, the object it represents has been lifted from the screen. SET messages
-provide information about movement. In the case of simple (x, y) positions,
-only the movement vector of the position itself can be calculated. For more
-complex objects such as fiducials, arguments like rotational position and
-acceleration are also included. ALIVE and SET messages are combined to create
-\emph{point\_down}, \emph{point\_move} and \emph{point\_up} events by the TUIO
-event driver.
-
-TUIO coordinates range from $0.0$ to $1.0$, with $(0.0, 0.0)$ being the left
-top corner of the touch surface and $(1.0, 1.0)$ the right bottom corner. The
-TUIO event driver scales these to pixel coordinates so that event area
-implementations can use pixel coordinates to determine whether an event is
-located within them. This transformation is also mentioned by the online
-TUIO specification \cite{TUIO_specification}:
-
-\begin{quote}
-    In order to compute the X and Y coordinates for the 2D profiles a TUIO
-    tracker implementation needs to divide these values by the actual sensor
-    dimension, while a TUIO client implementation consequently can scale these
-    values back to the actual screen dimension.
-\end{quote}
-
 \chapter{Test applications}
 \label{chapter:test-applications}