%%
%% $Id$
%%

\title{Lively HTML}

\subtitle{Seminar Web-based Development Environments}

\author{David~Jaeger \and Robert~Krahn}
\authorrunning{Jaeger, Krahn}
\institute{%
  Hasso-Plattner-Institut, Potsdam\\
  \email{\{firstname.lastname\}@student.hpi.uni-potsdam.de}
}
\maketitle

\bibliographystyle{splncs03}
\begin{abstract}
The Lively Kernel is a web-based development and runtime environment using the Morphic framework as its user interface. Morphic requires a graphic system that is capable of applying 2D transformations to graphical objects as well as support the modification of other graphical attributes. Currently, the Lively Kernel uses SVG for rendering. However, when displaying many graphical objects the performance of current SVG rendering systems is not sufficient to provide a satisfying usability. This is especially the case when a lot of textual content is rendered.

% This report presents the implementation and evaluation of an HTML-based rendering system.
The goal of this project is to implement and evaluate an HTML-based rendering system. We assume that Web browsers perform better rendering HTML. Additionally, we think that this approach will have other advantages, like enabling the usage of native widgets. We present our implementation approach and describe how the graphical requirements of an interactive system like the Lively Kernel can be mapped to HTML.
\end{abstract}

\section{Introduction}

The Lively Kernel (also Lively) is a collaborative and self-sustaining development and runtime environment for Web applications. It provides a rich and interactive graphics system by implementing the Morphic user interface \cite{Maloney:1995ec,Maloney:1995xw}. Currently Lively's rendering system is based on SVG\footnote{Scalable vector graphics (SVG) is an XML-based description language for two dimensional graphical objects} integrated into an XHTML document. The XHTML document can be loaded and modified in a Web browser.

The current rendering system is very flexible, giving a Lively developer direct control over how graphical elements are displayed. However, when visualizing larger amounts of objects like displaying several hundred classes in a system browser, the system becomes slow and unresponsive. This lessens the usability of Lively as a development platform. 

In this paper we present a prototypical implementation of a rendering system for Lively that is completely based on HTML. With this experiment we want to find out whether Web browsers are able to display interactive and graphical objects required by Lively Kernel\footnote{First with HTML version 5 and CSS version 3 Web browsers are able to display complex graphical objects like polygons and apply custom transformations without relying on SVG. Lively Kernel requires these capabilities for its user interface.}. We assume that HTML rendering is more optimized in Web browsers. Especially when displaying textual content we think that HTML rendering can provide better performance since Lively currently implements a manual text rendering process. 

% Since the HTML5 and CSS3 specification pr  and 

% We see the reason for this negative performance impact in the Web browser, which we assume is optimized for HTML rendering rather than SVG graphics. Furthermore, with the HTML specification, a Web browser has to provide a set of natively implemented input elements. These can be used as a counterpart to the SVG graphics lacking performance. Essentially, some SVG graphics have to be replaced with HTML widgets to achieve a better performance for text fields and lists. Unfortunately, an SVG scene graph, as employed in Lively, does not play well with HTML widgets. Consequently, the only way to integrate HTML elements into Lively is to switch the whole rendering subsystem from SVG to HTML with a complete HTML scene graph.

In addition to better performance for text content, an HTML scene graph can bring more significant benefits. 

\begin{description}

\item[Compatibility] The usage of HTML promises higher compatibility between Web browser, as HTML is more standardized and accepted in browsers than extensions like SVG. There is also a chance that Lively will run on the Internet Explorer.

\item[HTML Integration] Lively can integrate HTML elements residing in a surrounding HTML document, by \emph{livelifying} the HTML element and inserting it into its scene graph.

\end{description}


% When HTML rendering can really bring the mentioned advantages, there might come up the question, why SVG has been chosen at all at the beginning of the Lively project. The reason is that until now, it was impossible to implement the Morphic functionality with pure HTML, not even with the help of CSS. To be more precise, it was impossible to rotate or scale elements and draw complex shapes like ellipses or polygons. However, this has changed when the W3C\footnote{World Wide Web Consortium} has proposed new versions of HTML and CSS, namely HTML5 and CSS3. HTML5 provides a new \code{canvas} HTML element on which complex shapes can be drawn and CSS3 allows to apply transformations on HTML elements.

We first present an overview on Lively's rendering model in section \ref{sec:rendering_model}. We introduce our approach for integrating HTML rendering into Lively Kernel in section~\ref{sec:concept}. In section \ref{sec:implementation} we describe  how morphs are mapped to HTML elements.
% more details on the concrete implementation and show how it was possible to change the rendering subsystem while we still needed it for development.
Section \ref{sec:evaluation} evaluates the performance of the implementation. In \ref{sec:related_work} we introduce related work to HTML rendering in Lively. The last section concludes this report and provides ideas for future work.

\section{Lively's Rendering Subsystem}\label{sec:rendering_model}

The Lively Kernel has a modular rendering subsystem, which allows to replace facets of the graphical subsystem with moderate effort. Figure~\ref{fig:abstractMorphShapeMapping} provides a rough overview of the subsystem with its components.

\begin{figure}[htbp] %  figure placement: here, top, bottom, or page
   \centering
   \includegraphics[width=\textwidth]{images/BridgePatternUML.pdf}
   \caption{The rendering system in Lively Kernel uses the bridge pattern to separate the Morphic interface from its implementation.}
	 \label{fig:abstractMorphShapeMapping}
\end{figure}

The structure of the rendering subsystem follows the bridge pattern \cite{Gamma1995} which separates the Morphic interface from its concrete shape implementation. Morphic provides a variety of abstract graphical objects which are called \emph{morphs}. The concrete rendering is performed with the help of a graphical primitive called \emph{shape}. A morph does not need to have a concrete graphical representation. Two morphs of the same type can have different shapes. However, a morph and a shape always have a one-to-one relationship. The appearance of a shape is controlled by visual properties provided by the owning morph. 

\section{Concept}\label{sec:concept}

We have emphasized the modularity of Lively's rendering subsystem. Essentially, the separation of abstract morphs from their concrete graphical representation allows the switching to HTML rendering by only replacing the rendering specific shapes. In this section, we first show how this can be achieved in general and then show our approaches for a selection of core problems.

\subsection{Replacing the Rendering Subsystem}\label{sec:replacing_shapes}

The bridge pattern in the rendering subsystem narrows the needed reimplementation in Lively down to shapes and their supporting objects. Ideally, the Morphic interface and all code depending on morphs will remain untouched. This means, that only a minor part of the Lively Kernel needs to be changed. 

% Although only a small part of the system needs to be changed, the existence of a working shape implementation is essential for the Lively Kernel to run. How is it possible to program with Lively while we move from SVG rendering to HTML rendering? One solution is to execute rendering specific code either in an HTML context or an SVG context. As long as HTML rendering is not working, the Lively Kernel is executed in an SVG context, whereas all testing for the new HTML rendering system is done in an HTML context. A scenario that would even be more desirable is to have two separate Lively worlds on one Web site. One world is running with HTML, the other with SVG.

A mechanism that allows us to replace the rendering subsystem while we still use the Lively Kernel for development of the same is context oriented programming (COP). The details of this approach are described in section \ref{sec:implementation}.

\subsection{Core Issues for Implementing a Rendering Subsystem}\label{sec:implementation_issues}

The implementation of the HTML-based rendering requires various system changes. We identified five issues and discuss how they are addressed.

\subsubsection{HTML representation of existing graphical objects and their properties}

Lively uses an SVG scene graph, which is not intended for adding HTML elements. An HTML scene graph better fits this requirement and therefore should replace its SVG counterpart. SVG shape elements can be simply translated into HTML shape elements. Unfortunately, even a part of the Morphic implementation influences elements in the SVG scene graph. Thus, we should keep the structure of the HTML and SVG scene graph similar, so that changes in the Morphic code stays at a minimum.

\subsubsection{Transformations}

A transformation consists of three components, which are \emph{scaling}, \emph{rotation} and \emph{translation}. Lively stores a transformation in two forms: as a combined transformation matrix and as separate attributes. The matrix simplifies graphical operations, whereas attributes allow fast access to the components of a transformation. Each Morph has its own transformation, which is relative to the transformation of its parent morph. We should encourage the same ideas for our HTML specific shapes. 

\subsubsection{Serialization}

The current serialization of the Lively Kernel is based on the SVG DOM. However, the basic principle of serialization should be similar for HTML. Possible incompatibilities have to be found in advance. The only important thing is that all properties are serialized, so that a serialized Lively world can be completely restored.

\subsubsection{Text}

Text rendering will directly use the DOM tree for its representation, rather than shapes. The layouting of the text is handled by Lively. By following this approach, we can use a major part of the existing SVG text rendering mechanisms.
	
\subsubsection{Event System}

The event dispatching mechanism of Lively uses the Morphic hierarchy. The only point the dispatching interferes with interferes with the shape logic is the mapping of point in the world to the underlying shape. So the dispatching asks a shape for containment of a given point. 

%%%%%%
%%%%%%%%%%%%
%%%%%%

\section{Implementation}\label{sec:implementation}

We have identified five major problems for the implementation of HTML rendering. The mechanisms for the event system, text rendering and serialization are similar to the SVG implementation. In the first part of this section we will have a closer look at the problem of HTML representation of graphical objects. The second part covers the use of context oriented programming during our implementation phase. At the end, we show how native HTML widgets are integrated into Lively

\subsection{Mapping of Morphs into an HTML DOM Tree}

Figure~\ref{fig:domMappingExample} shows how a rectangular morph is rendered in Lively HTML. The graphical appearance of the morph seen by the user is shown at the top. The morph instance and its shape provide the interface for programmatically changing graphical attributes like the extent or color. They are shown below. The shape object is responsible for mapping those attributes to DOM elements. The generated subtree of the DOM is shown at the bottom.


% A morph can be represented in three different layers of Lively. Figure~\ref{fig:domMappingExample} shows these layers for a morph with a rectangular shape

\begin{figure}[ht] %  figure placement: here, top, bottom, or page
   \centering
   \includegraphics[width=0.8\textwidth]{images/exampleDOMMapping.pdf}
   \caption{This figure shows how a \code{Morph} with a \code{Rectangle} shape is displayed in Lively Kernel, represented programmatically in Lively, and rendered using the HTML DOM.}
   \label{fig:domMappingExample}
\end{figure}

% The presentation layer at the top is the rendered result of the Web browser. The object layer in the middle represents a morph as a collection of JavaScript objects. The layer at the bottom covers the DOM representation of a morph in Lively.
% 
% The most interesting layers for the implementation are the two lower ones. The mapping from a morph to its shape as depicted in the object layer is independent of the rendering. Thus, this part remains untouched for HTML rendering. Instead, the mapping from the shape object of the object layer to the HTML elements of the DOM layer are relevant for rendering.

For introducing a new rendering system the shape implementation needs to be changed because it is directly responsible for creating the graphical representation. In the following, we therefore describe how the shape implementation was modified to allow HTML-based rendering.

A shape renders itself to the DOM tree by creating an element appropriate for its shape. The relation between a shape object and its element in the DOM can be seen in the table of figure~\ref{tab:shapeMapping}. 

\begin{figure}
\centering
\begin{tabular}{|c|c|p{.35\linewidth}|}
\hline
\textbf{Shape Type (lively:type)} & \textbf{HTML element} & \textbf{Remarks}\\
\hline
rectangle & \code{div} & \\
\hline
ellipse & \code{div} & Use CSS3 \code{border-radius} property for round shape\\
\hline
polygon & \code{canvas} & Set all display properties via JavaScript \\
\hline
polyline & \code{canvas} & Set all display properties via JavaScript \\
\hline
\end{tabular}
\caption{Mapping of shape types to HTML elements}
\label{tab:shapeMapping}
\end{figure}

A shape object basically translates to two distinct HTML elements. \code{div}s are used for simple shapes, whereas \code{canvas} \cite{W3C:canvas} elements are used for complex shapes like polygons or polylines.

When the shape element has been created by the shape object it is subsequently wrapped into a \code{div} element representing the morph. It is important to notice that the morph object does not render itself into the DOM tree\footnote{Several specialized morphs, however, directly interact with the DOM. This breaks the abstraction created by the bridge pattern and needs to be considered when modifying the DOM representation}. Rendering is the responsibility of the shape.

The visual properties of a shape are added to the shape element by assigning a CSS declaration to their \code{style} attribute. In case of \code{canvas} elements, properties like color are set using the Canvas API. Table~\ref{tab:visualPropertyMapping} shows the mapping of visual properties to CSS attributes.

\begin{figure}[ht] %  figure placement: here, top, bottom, or page
  \centering
\begin{tabular}{|l|l|l|}
\hline
\textbf{visual property} & \textbf{CSS attribute} & \textbf{CSS3} \\
\hline
origin, rotation, scaling & transform & yes \\
\hline
extent & width, height & no \\
\hline
pivot point \footnote{can only indirectly specified by setting the shape's position} & top, left & no \\
\hline
fill color and opacity & background & partly \\
\hline
stroke color and opacity & foreground & partly \\
\hline
border color, opacity, radius, and width & border & partly \\
\hline
vertices \footnote{for polygon and polyline shapes} & canvas.beginPath & no \\
\hline
\end{tabular}
\caption{Visual properties are mapped to CSS attributes.}
\label{tab:visualPropertyMapping}
\end{figure}

Transformations are set with the \code{transform} \cite{W3C:transforms} property. It is a new property of CSS3 and its value is very similar to the transformation value of SVG elements. Therefore, many code involving transformations can be used from the existing implementation. 

Extent and the relative position of a shape in the morph are translated to CSS's standard positioning and extent attributes. For ellipses, we use rounded corners described with the \code{border-radius} CSS3 attribute value.

Color properties are assigned to the corresponding \code{foreground} and \code{background} attributes. A color can be of multiple types in the Lively Kernel. It can be a simple color consisting of a \emph{red}, \emph{green} and \emph{blue} value or it can be a gradient. Gradients are currently only supported for WebKit-based Web browsers, which support the \code{webkit-gradient} CSS attribute. Anyway, this can be extended to also support other Web browsers.

Vertices cannot be mapped to HTML \code{div} elements. Vertices have to be set using the canvas API introduced in HTML5.

\subsection{Using ContextJS}

We want to use the Lively Kernel while we are changing the rendering subsystem. Since the rendering subsystem is essential for a Lively world to render, an iterative development approach in not feasible. Additionally, we want to allow displaying an HTML and SVG world on the same Web document simultaneously. We were then able to modify the HTML world using running in the SVG world.

A solution that fulfills both requirements is context oriented programming. With this, we can execute rendering specific code either in an HTML context or an SVG context. As long as the HTML rendering subsystem is not finished, the Lively Kernel is executed in an SVG context, whereas all testing for the new HTML rendering subsystem is done in an HTML context. Once the HTML rendering subsystem is completed, the context can be assigned individually on world creation.

\subsubsection{Context-specific Code}

We have identified the shape classes and their supporting objects as the primary point requiring reimplementation in order to support HTML rendering. The Morphic interface, with some exceptions, does not need to be changed. As a result, we only need to make the shape code context-aware. This can be seen in figure~\ref{fig:layerActivation}.

\begin{figure}[htbp] %  figure placement: here, top, bottom, or page
   \centering
   \includegraphics[width=0.8\textwidth]{images/layerActivation.pdf}
   \caption{Locations for layered code and the different types of layer activation}
   \label{fig:layerActivation}
\end{figure}

With context oriented programming, there will be one shape implementation for HTML and another one for SVG. In the figure, the HTML context is used by activating the HTML layer.

\subsubsection{Layer Activation and Context Propagation}

In order to execute the shape code within a specific context, the corresponding layer first has to be activated. A layer can be activated in the ways listed below and as shown in figure~\ref{fig:layerActivation}.

\begin{description}
\item[Object Scope] The layer can be activated programmatically by explicitly calling \code{setWithLayers} on an object. If this object initiates the execution of code involving the layered code, this code is executed under the layer's context.  
\item[Asynchronous Events] Layer activation is lost when code is called asynchronously. Reasons for such asynchronous code executions are system events or scheduling. In order to avoid execution of shape code without a context, we have ensured that the same layer is activated in the asynchronous call, which was activated at the initiation of an asynchronous call.
\item[User Events] These events are similar to the \emph{asynchronous code} above and are initiated by user interaction like mouse moves or keyboard usage. Here it also has to be ensured that the activated layer is propagated across user event callbacks. 
\end{description}

\subsection{Widgets based on HTML form and text elements}

  HTML provides form and text elements specialized for certain tasks. Input elements, for instance, cannot only appear as text inputs but can also be rendered as sliders, search panels, or buttons. These widgets are rendered like native operating system widgets, allowing application developers to create a more familiar look-and-feel.

To really benefit from HTML-based rendering, Lively users should be able to use these widgets as normal morphs. We implemented morphs providing access to widget attributes for some of these widgets. Figure~\ref{fig:widgets} shows the widget set currently supported by Lively HTML. In figure~\ref{fig:browser} a system browser that uses these new morphs can be seen. The browser provides a better usability than existing Lively tools when a lot of data, for example a big class like \code{TextMorph}, is viewed.

The current implementation of the HTML widgets can be considered prototypical since the morphs directly interact with the DOM elements. This scheme breaks the abstraction of the bridge pattern and shape elements should be used to wrap those elements instead.

\begin{figure}[htbp] %  figure placement: here, top, bottom, or page
   \centering
   \includegraphics[width=0.85\textwidth]{images/HTMLWidgets.png}
   \caption{HTML widgets.}
   \label{fig:widgets}
\end{figure}



\begin{figure}[htbp] %  figure placement: here, top, bottom, or page
   \centering
   \includegraphics[width=0.85\textwidth]{images/HTMLBrowser.png}
   \caption{HTML browser.}
   \label{fig:browser}
\end{figure}


\section{Evaluation}\label{sec:evaluation}

We measured the performance of our implementation by running four different benchmarks\footnote{Specification of the test system:\\Macbook Pro, 2.16 GHz Core 2 Duo, 3 GB RAM\\Google Chrome 5 (Mozilla\/5.0 (Macintosh; U; Intel Mac OS X 10\_6\_4; en-US) AppleWebKit\/533.4 (KHTML, like Gecko) Chrome\/5.0.375.99 Safari\/533.4)}. Each benchmark was run with the HTML version (both with ContextJS deactivated and activated) and with the SVG version.

\begin{description}
  \item[Ellipse Benchmark] This benchmark creates moving and spinning ellipses to measure the performance of transformations. We record the frames per second during a fixed interval.

  \item[Mouse click and mouse move benchmark] Measures how fast mouse events are dispatched. This simulates typical user inputs. Measurements were recorded in milliseconds.
  
  \item[List selection benchmark] We compare how fast list elements can be selected. The list element in the HTML version is a new list morph that uses only one shape being able to manage a list of text items. In the SVG version the list morph uses scroll morphs, clip morphs, and textmorphs for that task. This can be observed, for example, when interacting with lists having many entries. Measurements were recorded in milliseconds.
\end{description}

\begin{figure}[ht] %  figure placement: here, top, bottom, or page
   \centering
   \includegraphics[width=\textwidth]{images/LivelyHTMLPerformance.png}
   \caption{Results of the benchmark comparing the performance of the HTML and SVG version.}
   \label{fig:benchmarks}
\end{figure}

Figure~\ref{fig:benchmarks} shows the result of the benchmarks. The ellipse benchmark was twice as fast in the SVG version than in HTML. This is unexpected and negates the theory that HTML rendering is better optimized than SVG rendering. The reason for that is probably the following: For modifying the CSS transformations the transformation data has to be converted into a string representation. The API for setting the CSS attributes without the need for string conversion is part of the DOM Level 2 CSS specification\footnote{\texttt{http://www.w3.org/TR/DOM-Level-2-Style\/css.html\#CSS\-CSSStyleDeclaration}}
, however, in none of the browsers we used for development was this  interface implemented or working. SVG on the other hand, directly uses matrices for transformation which is significantly faster. The ellipse benchmark also shows the performance impact of ContextJS. When activating the HTML rendering layer the system was 50 percent slower than without it.

The mouse event benchmarks show that the HTML version is more than 25 percent faster than the HTML version. This is also not surprising since the event dispatch mechanism that manually dispatches events using the morphic hierarchy is mainly the same as in the SVG-based Lively. However, the events are first captured by the canvas element that is in HTML Lively a HTML element. This element seems to be able to process the events faster. The results indicate that replacing the existing manual event dispatch mechanism with the browser-based event dispatch might be an effective optimization.

In the list selection benchmark the HTML version has a significant performance advantage. Selecting list items is almost 10 times faster than in the SVG version. Since we used a special HTML element that is able to scroll and directly manages its list items it becomes apparent that having native elements is an advantage compared to SVG where those elements are not existing.

Our evaluation results show, that we could improve performance for user interaction and for elements that play an important role in the tooling of Lively. We noticed a performance loss for transformations. Transformations are especially important for displaying animated non-textual content and we conclude that Lively HTML is not so well suited for these task than the SVG-based version. However, support for transformations is still in development and no browser seems to be fully specification compliant. We assume that this will change in the future because there is a trend towards rich graphic Web applications.

\section{Related Work}\label{sec:related_work}

Several projects experimented with the rendering system of the Lively Kernel.

To create a standalone version of Lively that is independent of Web browsers, the Gezira 2D graphic system was used for rendering \cite{Alan-Kay:2008fk}. This project was used for gaining inside into a minimal graphical system and was not continued.

Based on the DOM emulation module implemented by the Gezira project there also exists an implementation using the JavaFX scene graph for rendering morphs\cite{Palacz:2008uq}. This project was not continued.

The HTML5 canvas element was used to render an entire Lively world using only raster graphics \cite{Ingalls:2009}. Also this project was not continued because the rendering performance of the canvas element turned out to be inferior compared with SVG rendering.

The Qt framework was used as a rendering system for Lively \cite{al:2009kx}. It allows to display morphs using Qt widgets. For running Lively Qt an installation of the Qt platform or a browser plugin is necessary.



% 
%  in a single \emph{canvas} element
%  In a project 
% The rendering system of the Lively Kernel was  
% 
% Dan Ingalls, developer of the Lively Kernel, has recently finished a prototype\cite{Ingalls:2009}, which is rendering an entire Lively world in a single \emph{canvas} element. Nevertheless, this prototype does not support the integration of HTML widgets, either. It has no scene graph to which a widget could be attached to. In the following sections, we propose a new approach for HTML rendering in Lively. We provide an explicit HTML scene graph, which makes use of established HTML elements where possible and only employs advanced HTML5 and CSS3 features when there is no alternative.


\section{Conclusion}\label{sec:conclusion}

We have successfully created a prototypical version of HTML-based rendering for the Lively Kernel. We showed that it is possible to implement all necessary graphical operations and structures using CSS and HTML.

We evaluated our approach to determine the performance characteristics. We found out that the HTML approach is much faster for text and list based tools (i.e. for development tools) since we were able to use specialized HTML elements. Thereby, the overall usability of the system is improved. The execution of transformations, however, is slower and it can be expected that a HTML-based system will not perform as well as the SVG version for Lively worlds with animated graphical objects.

We used ContextJS to be able to work with Lively's development tools and change its underlaying rendering system at the same time. We were able to mitigate the performance impact of ContextJS by merging layered code together with the base layer to extend the existing system statically.

Although we have not implemented SVG-based shapes into the HTML version, we consider that this is an option to still support vector graphics. This would make sense for objects that can be better rendered in SVG as in HTML, for example curves. 

% allowed to scope changes and to apply them to a Lively world running parallel 

% Although it has not been implemented yet, it would also be possible to continue using SVG shapes. Such shapes could be used for certain shape types like curves or polygons only. This would mean that we would able to easily mix different rendering types with each other. However, using only SVG shapes will not resolve the issue with transformation performance since transformations will still be applied by means of CSS. Only this can guarantee compatibility between all types of shapes. 

% Although the HTML rendering in Lively Kernel has some disadvantages, it still brings the benefit of higher text and list performance and it plays nicely together with surrounding HTML documents. As a consequence, one could think of replacing the existing SVG rendering subsystem of Lively with the HTML rendering subsystem, which still supports standalone SVG shapes.

\subsection{Future Work}

We think it would be a valuable contribution to the Lively Kernel to integrate the new rendering system. The overall gain of usability and the capability to better support mobile devices like the iPad (because of the improved performance and native widgets) compensates for the transformation performance loss. We also expect that new Web browser versions will better support CSS transformations. Steps towards an integration are the following: Create a converter that transforms existing Lively SVG worlds into HTML documents, improve the text support for native HTML text (rich text is not yet supported), and replace the old morphs with the more performant native widgets.

We started experimenting with augmenting HTML documents. Loading Lively Kernel on-demand into an existing document enables to embed morphs as well as modify and script existing HTML elements. We think further experiments with that approach can give valuable insights concerning document scripting and end-user programming.


% \bibliographystyle{splncs}
\bibliography{references}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "Pape_2010_WDE_TeXParagraphLayout"
%%% End: 

