+\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
+ \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}
+
+\subsection{Why do we still use static PDFs}
+
+Despite their limitations, we still use static, boring old PDFs. Particularly in scientific communication.
+\begin{itemize}
+ \item They are portable; you can write an amazing document in Mathematica/Matlab but it
+ \item Scientific journals would need to adapt to other formats and this is not worth the effort
+ \item No network connection is required to view a PDF (although DRM might change this?)
+ \item All rescources are stored in a single file; a website is stored accross many seperate files (call this a ``distributed'' document format?)
+ \item You can create PDFs easily using desktop processing WYSIWYG editors; WYSIWYG editors for web based documents are worthless due to the more complex content
+ \item Until Javascript becomes part of the PDF standard, including Javascript in PDF documents will not become widespread
+ \item Once you complicate a PDF by adding Javascript, it becomes more complicated to create; it is simply easier to use a series of static figures than to embed a shader in your document. Even for people that know WebGL.
+\end{itemize}
+
+\rephrase{3. Here are the ways document standards specify precision (or don't)}
+
+\section{Precision in Modern Document Formats}
+
+\rephrase{All the above 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. Sorry to make you read it all.}
+
+
+
+\begin{itemize}
+ \item Implementations of PostScript and PDF must by definition restrict themselves to IEEE binary32 ``single precision''\footnote{The original IEEE-754 defined single, double and extended precisions; in the revision these were renamed to binary32, binary64 and binary128 to explicitly state the base and number of bits}
+ 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}
+ \item Numerical computation packages such as Mathematica and Maple use arbitrary precision floats
+ \begin{itemize}
+ \item Mathematica is not open source which is an issue when publishing scientific research (because people who do not fork out money for Mathematica cannot verify results)
+ \item What about Maple? \cite{HFP} and \cite{fousse2007mpfr} both mention it being buggy.
+ \item Octave and Matlab use fixed precision doubles
+ \end{itemize}
+\end{itemize}
+
+The use of IEEE binary32 floats in the PostScript and PDF standards is not surprising if we consider that these documents are oriented towards representing static pages. They don't actually need higher precision to do this; 32 bits is more than sufficient for A4 paper.
+
+\rephrase{4. Here is IEEE-754 which is what these standards use}