+Splines are continuous curves formed from piecewise polynomial segments. A polynomial of $n$th degree is defined by $n$ constants $\{a_0, a_1, ... a_n\}$ and:
+\begin{align}
+ y(x) &= \displaystyle\sum_{k=0}^n a_k x^k
+\end{align}
+
+
+A straight line is simply a polynomial of $0$th degree. Splines may be rasterised by sampling of $y(x)$ at a number of points $x_i$ and rendering straight lines between $(x_i, y_i)$ and $(x_{i+1}, y_{i+1})$ as discussed in Section \ref{Straight Lines}. More direct algorithms for drawing splines based upon Brasenham and Wu's algorithms also exist\cite{citationneeded}.
+
+There are many different ways to define a spline. One approach is to specify ``knots'' on the spline and solve for the cooefficients to generate a cubic spline ($n = 3$) passing through the points. Beziers are a popular spline which can be created in GUI based graphics editors using several ``control points'' which themselves are not part of the curve.
+
+\subsubsection{Bezier Curves}
+\input{chapters/Background_Bezier}
+
+\subsection{Shading}
+
+Algorithms for shading on vector displays involved drawing equally spaced lines within a region; this is limited both in the complexity of shading and the performance required to compute the lines\cite{brassel1979analgorithm}.
+
+On raster displays, shading is typically based upon Lane's algorithm of 1983\cite{lane1983analgorithm} which is implemented in the GPU \cite{kilgard2012gpu}
+
+\rephrase{6. Sort of starts here... or at least background does}
+
+\subsection{Rendering Vector Graphics on the GPU}
+
+Traditionally, vector graphics have been rasterized by the CPU before being sent to the GPU for drawing\cite{kilgard2012gpu}. Lots of people would like to change this \cite{worth2003xr, loop2007rendering, rice2008openvg, kilgard2012gpu, green2007improved} ... \rephrase{All of these are things David found except kilgard which I thought I found and then realised David already had it :S}
+
+\rephrase{2. Here are the ways documents are structured ... we got here eventually}
+
+\section{Document Representations}
+
+\rephrase{The file format can be either human readable\footnote{For some definition of human and some definition of readable} or binary\footnote{So, our viewer is basically a DOM style but stored in a binary format}. Can also be compressed or not. Here we are interested in how the document is interpreted or traversed in order to produce graphics output.}
+
+\subsection{Interpreted Model}
+
+\rephrase{Did I just invent that terminology or did I read it in a paper? Is there actually existing terminology for this that sounds similar enough to ``Document Object Model'' for me to compare them side by side?}
+
+\begin{itemize}
+ \item This model treats a document as the source code program which produces graphics
+ \item Arose from the desire to produce printed documents using computers (which were still limited to text only displays).
+ \item Typed by hand or (later) generated by a GUI program
+ \item PostScript --- largely supersceded by PDF on the desktop but still used by printers\footnote{Desktop pdf viewers can still cope with PS, but I wonder if a smartphone pdf viewer would implement it?}
+ \item \TeX --- Predates PostScript! {\LaTeX } is being used to create this very document and until now I didn't even have it here!
+ \begin{itemize}
+ \item I don't really want to go down the path of investigating the billion steps involved in getting \LaTeX into an actually viewable format
+ \item There are interpreters (usually WYSIWYG editors) for \LaTeX though
+ \item Maybe if \LaTeX were more popular there would be desktop viewers that converted \LaTeX directly into graphics
+ \end{itemize}
+ \item Potential for dynamic content, interactivity; dynamic PostScript, enhanced Postscript
+
+ \item Scientific Computing --- Mathematica, Matlab, IPython Notebook --- The document and the code that produces it are stored together
+ \item Problems with security --- Turing complete, can be exploited easily
+\end{itemize}
+
+\subsection{Crippled Interpreted Model}
+
+\rephrase{I'm pretty sure I made that one up}
+
+\begin{itemize}
+ \item PDF is PostScript but without the Turing Completeness
+ \item Solves security issues, more efficient
+\end{itemize}
+
+\subsection{Document Object Model}
+
+\begin{itemize}
+ \item DOM = Tree of nodes; node may have attributes, children, data
+ \item XML (SGML) is the standard language used to represent documents in the DOM
+ \item XML is plain text
+ \item SVG is a standard for a vector graphics language conforming to XML (ie: a DOM format)
+ \item CSS style sheets represent more complicated styling on objects in the DOM
+\end{itemize}
+
+\subsection{Blurring the Line --- Javascript}
+
+\begin{itemize}
+ \item The document is expressed in DOM format using XML/HTML/SVG
+ \item A Javascript program is run which can modify the DOM
+ \item At a high level this may be simply changing attributes of elements dynamically
+ \item For low level control there is canvas2D and even WebGL which gives direct access to OpenGL functions
+ \item Javascript can be used to make a HTML/SVG interactive