+\section{Primitives in Vector Graphics Formats (and how they are Rendered)}
+
+\subsection{Bezier Curves}
+\rephrase{I did an ipython notebook on this in February, but I forgot all of it}
+
+\subsection{Text}
+Text is just Bezier Curves
+
+\subsection{Shapes}
+Shapes are just bezier curves joined together.
+
+\subsection{Other Things}
+We don't really care about other things (ie: Colour gradients etc) in this report.
+
+\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)
+\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
+ \begin{itemize}
+ \item Overlooking the fact that the SVG standard already allows for interactive elements...
+ \end{itemize}
+ \item Javascript is now becoming used even in desktop environments and programs (Windows 8, GNOME 3, Cinnamon, Game Maker Studio) ({\bf shudder})
+ \item There are also a range of papers about including Javascript in PDF ``Pixels or Perish'' being the only one we have actually read\cite{hayes2012pixels}
+ \begin{itemize}
+ \item I have no idea how this works; PDF is based on PostScript... it seems very circular to be using a programming language to modify a document that is modelled on being a (non turing complete) program
+ \item This is yet more proof that people will converge towards solutions that ``work'' rather than those that are optimal or elegant
+ \item I guess it's too much effort to make HTML look like PDF (or vice versa) so we could phase one out
+ \end{itemize}
+\end{itemize}
+
+
+
+
+\section{Precision Limitations of Modern Documents}
+
+\rephrase{All this is very interesting and provides important context, but it is not actually directly related to the problem of infinite precision which we are going to try and solve}.
+
+\subsection{Limitations Imposed By Standards}
+\begin{itemize}
+ \item Implementations of PostScript and PDF must by definition restrict themselves to IEEE binary32 ``single precision'' floating point number representations in order to conform to the standards\cite{plrm, pdfref17}.
+ \item Implementations of SVG are by definition required to use IEEE binary32 as a {\bf minimum}. ``High Quality'' SVG viewers are required to use at least IEEE binary64.\cite{svg2011-1.1}
+\end{itemize}