ARGH

diff --git a/chapters/Background.tex b/chapters/Background.tex
index 5398351..8b8ad50 100644 (file)
--- a/chapters/Background.tex
+++ b/chapters/Background.tex
@@ -31,7 +31,7 @@ It is of some historical significance that vector display devices were popular d
 
 %\cite{brassel1979analgorithm}; %\cite{lane1983analgorithm}.
 
 
 %\cite{brassel1979analgorithm}; %\cite{lane1983analgorithm}.
 

-\subsection{Compositing}\label{Compositing and the Painter's Model}
+\subsection{Compositing}\label{Compositing}

 
 %So far we have discussed techniques for rendering vector graphics primitives in isolation, with no regard to the overall structure of a document which may contain many thousands of primitives. A straight forward approach would be to render all elements sequentially to the display, with the most recently drawn pixels overwriting lower elements. Such an approach is particularly inconvenient for anti-aliased images where colours must appear to smoothly blur between the edge of a primitive and any drawn underneath it.
 
 
 %So far we have discussed techniques for rendering vector graphics primitives in isolation, with no regard to the overall structure of a document which may contain many thousands of primitives. A straight forward approach would be to render all elements sequentially to the display, with the most recently drawn pixels overwriting lower elements. Such an approach is particularly inconvenient for anti-aliased images where colours must appear to smoothly blur between the edge of a primitive and any drawn underneath it.
 


@@ -50,9 +50,9 @@ The PostScript and PDF standards, as well as the OpenGL API also use a painter's
 
 \subsection{Rasterisation on the CPU and GPU}
 
 
 \subsection{Rasterisation on the CPU and GPU}
 

-Traditionally, vector images have been rasterized by the CPU before being sent to a specialised Graphics Processing Unit (GPU) for drawing\cite{computergraphics2}. Rasterisation of simple primitives such as lines and triangles have been supported directly by GPUs for some time through the OpenGL standard\cite{openglspec}. However complex shapes (including those based on B{\'e}zier curves such as font glyphs) must either be rasterised entirely by the CPU or decomposed into simpler primitives that the GPU itself can directly rasterise. There is a significant body of research devoted to improving the performance of rendering such primitives using the latter approach, mostly based around the OpenGL API\cite{robart2009openvg, leymarie1992fast, frisken2000adaptively, green2007improved, loop2005resolution, loop2007rendering}. Recently Mark Kilgard of the NVIDIA Corporation described an extension to OpenGL for NVIDIA GPUs capable of drawing and shading vector paths\cite{kilgard2012gpu,kilgard300programming}. From this development it seems that rasterization of vector graphics may eventually become possible upon the GPU.openglspec
+Traditionally, vector images have been rasterized by the CPU before being sent to a specialised Graphics Processing Unit (GPU) for drawing\cite{computergraphics2}. Rasterisation of simple primitives such as lines and triangles have been supported directly by GPUs for some time through the OpenGL standard\cite{openglspec}. However complex shapes (including those based on B{\'e}zier curves such as font glyphs) must either be rasterised entirely by the CPU or decomposed into simpler primitives that the GPU itself can directly rasterise. There is a significant body of research devoted to improving the performance of rendering such primitives using the latter approach, mostly based around the OpenGL\cite{openglspec} API\cite{robart2009openvg, leymarie1992fast, frisken2000adaptively, green2007improved, loop2005resolution, loop2007rendering}. Recently Mark Kilgard of the NVIDIA Corporation described an extension to OpenGL for NVIDIA GPUs capable of drawing and shading vector paths\cite{kilgard2012gpu,kilgard300programming}. From this development it seems that rasterization of vector graphics may eventually become possible upon the GPU.

 
 

-It is not entirely clear how well supported the IEEE-754 standard for floating point computation (which we will discuss in Section \ref{}) is amongst GPUs\footnote{Informal technical articles are prevelant on the internet --- Eg: Regarding the Dolphin Wii GPU Emulator: \url{https://dolphin-emu.org/blog} (accessed 2014-05-22)}. Although the OpenGL API does use IEEE-754 number representations, research by Hillesland and Lastra in 2004 suggested that many GPUs were not internally compliant with the standard\cite{hillesland2004paranoia}. %Arbitrary precision arithmetic, is provided by many software libraries for CPU based calculations
+It is not entirely clear how well supported the IEEE-754 standard for floating point computation is amongst GPUs\footnote{Informal technical articles are abundant on the internet --- Eg: Regarding the Dolphin Wii GPU Emulator: \url{https://dolphin-emu.org/blog} (accessed 2014-05-22)}. Although the OpenGL API does use IEEE-754 number representations, research by Hillesland and Lastra in 2004 suggested that many GPUs were not internally compliant with the standard\cite{hillesland2004paranoia}. %Arbitrary precision arithmetic, is provided by many software libraries for CPU based calculations

 
  \pagebreak
 \section{Document Representations}\label{Document Representations}
 
  \pagebreak
 \section{Document Representations}\label{Document Representations}


@@ -107,7 +107,7 @@ The Number type does differ slightly from IEEE-754 in that there is only a singl
 
 \section{Number Representations}\label{Number Representations}
 
 
 \section{Number Representations}\label{Number Representations}
 

-Consider a value of $7.25 = 2^2 + 2^1 + 2^0 + 2^{-2}$. In binary (base 2), this could be written as $111.01_2$ Such a value would require 5 binary digits (bits) of memory to represent exactly in computer hardware. Some values, for example $7.3$ can not be represented exactly in one base (decimal) but not another; in binary the sequence $111.010\text{...}_2$ will never terminate. A rational value such as $\frac{7}{3}$ could not be represented exactly in any base, but could be represented by the combination of a numerator $7 = 111_2$ and denominator $3 = 11_2$. Lastly, some values such as $e \approx 2.81\text{...}$ can only be expressed exactly using a symbolical system --- in this case as the result of an infinite summation --- $e = \displaystyle\sum_n=0^{\infty} (-1)^{n}\frac{1}{n!}$
+Consider a value of $7.25 = 2^2 + 2^1 + 2^0 + 2^{-2}$. In binary (base 2), this could be written as $111.01_2$ Such a value would require 5 binary digits (bits) of memory to represent exactly in computer hardware. Some values, for example $7.3$ can not be represented exactly in one base (decimal) but not another; in binary the sequence $111.010\text{...}_2$ will never terminate. A rational value such as $\frac{7}{3}$ could not be represented exactly in any base, but could be represented by the combination of a numerator $7 = 111_2$ and denominator $3 = 11_2$. Lastly, some values such as $e \approx 2.81\text{...}$ can only be expressed exactly using a symbolical system --- in this case as the result of an infinite summation --- $e = \displaystyle\sum_n=0^{\infty}\frac{1}{n!}$

 
 Modern computer hardware typically supports integer and floating-point number representations and operations. Due to physical limitations, the size of these representations is limited; this is the fundamental source of both limits on range and precision in computer based calculations. 
 
 
 Modern computer hardware typically supports integer and floating-point number representations and operations. Due to physical limitations, the size of these representations is limited; this is the fundamental source of both limits on range and precision in computer based calculations. 
 

diff --git a/chapters/Background_Fonts.tex b/chapters/Background_Fonts.tex
index 9044932..8f02458 100644 (file)
--- a/chapters/Background_Fonts.tex
+++ b/chapters/Background_Fonts.tex
@@ -11,11 +11,11 @@
        \includegraphics[width=0.7\textwidth]{figures/z.png}
 \end{figure}
 \end{minipage}
        \includegraphics[width=0.7\textwidth]{figures/z.png}
 \end{figure}
 \end{minipage}

-       \caption{a) Vector glyph for the letter Z b) Screenshot showing B{\'e}zier control points in Inkscape}
+       \caption{a) Vector glyph for the letter Z b) Screenshot showing B{\'e}zier control points in Inkscape}\label{zglyph}

 \end{figure}
 
 A the term ``font'' refers to a set of images used to represent text on a graphical display. In 1983, Donald Knuth published ``The METAFONT Book'' which described a vector approach to specifying fonts and a program for creating these fonts\cite{knuth1983metafont}. Previously, only rasterised font images (glyphs) were popular; as can be seen from the zooming in Figure \ref{vector-vs-raster-scaled} this can be problematic given the prevelance of textual information at different scales and on different resolution displays. 
 
 \end{figure}
 
 A the term ``font'' refers to a set of images used to represent text on a graphical display. In 1983, Donald Knuth published ``The METAFONT Book'' which described a vector approach to specifying fonts and a program for creating these fonts\cite{knuth1983metafont}. Previously, only rasterised font images (glyphs) were popular; as can be seen from the zooming in Figure \ref{vector-vs-raster-scaled} this can be problematic given the prevelance of textual information at different scales and on different resolution displays. 
 

-Knuth used B{\'e}zier Cubic Splines to define ``pleasing'' curves in METAFONT, and this approach is still used in modern vector fonts. Since the paths used to render an individual glyph are used far more commonly than general curves, document formats do not require such curves to be specified in situ, but allow for a choice between a number of internal fonts or externally specified fonts. In the case of Knuth's typesetting language \TeX, fonts were intended to be created using METAFONT\cite{knuth}. Figure \ref{zglyph} shows a $\mathscr{Z}$ (Z) in Ralph Smith's Formal Script font as produced by \LaTeX with the start and end points of each Cubic B{\'e}zier identified.
+Knuth used B{\'e}zier Cubic Splines to define ``pleasing'' curves in METAFONT, and this approach is still used in modern vector fonts. Since the paths used to render an individual glyph are used far more commonly than general curves, document formats do not require such curves to be specified in situ, but allow for a choice between a number of internal fonts or externally specified fonts. In the case of Knuth's typesetting language \TeX, fonts were intended to be created using METAFONT\cite{knuth1983metafont}. Figure \ref{zglyph} shows a $\mathscr{Z}$ (script Z) produced by \LaTeX with B{\'e}zier cubics identified.

 
 
 
 

diff --git a/chapters/Progress.tex b/chapters/Progress.tex
index 475bc07..5727c2a 100644 (file)
--- a/chapters/Progress.tex
+++ b/chapters/Progress.tex
@@ -28,6 +28,9 @@ The literature examined in Chapter\ref{Background} can broadly classed into thre
 To improve the Literature Review we could consider the following topics in more detail:
 \begin{enumerate}
        \item Additional approaches to arbitrary precision possibly including symbolic computation
 To improve the Literature Review we could consider the following topics in more detail:
 \begin{enumerate}
        \item Additional approaches to arbitrary precision possibly including symbolic computation

+       \begin{itemize}
+               \item The Mathematica computational package claims to use symbolic computation, but we have yet to explore this field
+       \end{itemize}

        \item Floating point errors in the context of computing B\'{e}zier Curves or similar
        \item Algorithms for reducing overall error other than Fast2Sum
        \item Alternative number representations such as rationals (eg: $\frac{1}{3}$)
        \item Floating point errors in the context of computing B\'{e}zier Curves or similar
        \item Algorithms for reducing overall error other than Fast2Sum
        \item Alternative number representations such as rationals (eg: $\frac{1}{3}$)

diff --git a/thesis.pdf b/thesis.pdf
index 8137c3e..3677ded 100644 (file)
Binary files a/thesis.pdf and b/thesis.pdf differ