From: David Gow Date: Tue, 21 Oct 2014 06:56:50 +0000 (+0800) Subject: All of the apologies. X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=commitdiff_plain;h=d14c6178d80add8968c936a33a2a74baa726b670 All of the apologies. --- diff --git a/DavidSeminarAbstract b/DavidSeminarAbstract new file mode 100644 index 0000000..17cceb3 --- /dev/null +++ b/DavidSeminarAbstract @@ -0,0 +1,17 @@ +Precision in vector documents: a spatial approach + +Despite being scalable, vector images are typically specified and manipulated +with fixed-precision numbers. Existing formats therefore are unable to store +documents which need greater precision, and existing viewers perform coordinate +system transforms at a fixed precision, limiting the amount any document may be +"zoomed". + +Using existing arbitrary-precision numeric types can resolve these issues, but +often at a significant or infeasible performance penalty. By taking into +account the spatial nature of the data, we can store and view documents to an +arbitrary precision with little-to-no performance impact. This is achieved by +clipping the document's constituent Bézier paths to nodes in a quadtree. + +We'll discuss the artefacts caused by low-precision, the theory and +implementation of our quadtree-based format and some remaining issues and future +possibilities with the technique. diff --git a/cshonours.cls b/cshonours.cls new file mode 100644 index 0000000..c2e0638 --- /dev/null +++ b/cshonours.cls @@ -0,0 +1,798 @@ +%% +%% This is file `cshonours.cls' modified by Cara MacNish from +%% `report.cls', August 1999. +%% It is described in more detail in the accompanying example +%% document, `cshonours.tex'. +%% +%% The following refers to the original report.cls. +%% The original source files were: +%% +%% classes.dtx (with options: `report') +%% +%% This is a generated file. +%% +%% Copyright 1993 1994 1995 1996 1997 1998 1999 +%% The LaTeX3 Project and any individual authors listed elsewhere +%% in this file. +%% +%% This file is part of the LaTeX2e system. +%% ---------------------------------------- +%% +%% It may be distributed under the terms of the LaTeX Project Public +%% License, as described in lppl.txt in the base LaTeX distribution. +%% Either version 1.0 or, at your option, any later version. +%% \CharacterTable +%% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z +%% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z +%% Digits \0\1\2\3\4\5\6\7\8\9 +%% Exclamation \! Double quote \" Hash (number) \# +%% Dollar \$ Percent \% Ampersand \& +%% Acute accent \' Left paren \( Right paren \) +%% Asterisk \* Plus \+ Comma \, +%% Minus \- Point \. Solidus \/ +%% Colon \: Semicolon \; Less than \< +%% Equals \= Greater than \> Question mark \? +%% Commercial at \@ Left bracket \[ Backslash \\ +%% Right bracket \] Circumflex \^ Underscore \_ +%% Grave accent \` Left brace \{ Vertical bar \| +%% Right brace \} Tilde \~} +\NeedsTeXFormat{LaTeX2e}[1995/12/01] +\ProvidesClass{cshonours} + [2000/09/13 v1.4a Modified from Standard LaTeX document +class report.cls by Cara MacNish August 1999/September 2000] +\newcommand\@ptsize{} +\newif\if@restonecol +\newif\if@titlepage +\@titlepagetrue +\newif\if@openright +\if@compatibility\else +\DeclareOption{a4paper} + {\setlength\paperheight {297mm}% + \setlength\paperwidth {210mm}} +\DeclareOption{a5paper} + {\setlength\paperheight {210mm}% + \setlength\paperwidth {148mm}} +\DeclareOption{b5paper} + {\setlength\paperheight {250mm}% + \setlength\paperwidth {176mm}} +\DeclareOption{letterpaper} + {\setlength\paperheight {11in}% + \setlength\paperwidth {8.5in}} +\DeclareOption{legalpaper} + {\setlength\paperheight {14in}% + \setlength\paperwidth {8.5in}} +\DeclareOption{executivepaper} + {\setlength\paperheight {10.5in}% + \setlength\paperwidth {7.25in}} +\DeclareOption{landscape} + {\setlength\@tempdima {\paperheight}% + \setlength\paperheight {\paperwidth}% + \setlength\paperwidth {\@tempdima}} +\fi +\if@compatibility + \renewcommand\@ptsize{0} +\else +\DeclareOption{10pt}{\renewcommand\@ptsize{0}} +\fi +\DeclareOption{11pt}{\renewcommand\@ptsize{1}} +\DeclareOption{12pt}{\renewcommand\@ptsize{2}} +\if@compatibility\else +\DeclareOption{oneside}{\@twosidefalse \@mparswitchfalse} +\fi +\DeclareOption{twoside}{\@twosidetrue \@mparswitchtrue} +\DeclareOption{draft}{\setlength\overfullrule{5pt}} +\if@compatibility\else +\DeclareOption{final}{\setlength\overfullrule{0pt}} +\fi +\DeclareOption{titlepage}{\@titlepagetrue} +\if@compatibility\else +\DeclareOption{notitlepage}{\@titlepagefalse} +\fi +\if@compatibility +\else +\DeclareOption{openright}{\@openrighttrue} +\DeclareOption{openany}{\@openrightfalse} +\fi +\if@compatibility\else +\DeclareOption{onecolumn}{\@twocolumnfalse} +\fi +\DeclareOption{twocolumn}{\@twocolumntrue} +\DeclareOption{leqno}{\input{leqno.clo}} +\DeclareOption{fleqn}{\input{fleqn.clo}} +\DeclareOption{openbib}{% + \AtEndOfPackage{% + \renewcommand\@openbib@code{% + \advance\leftmargin\bibindent + \itemindent -\bibindent + \listparindent \itemindent + \parsep \z@ + }% + \renewcommand\newblock{\par}}% +} +\ExecuteOptions{a4paper,12pt,oneside,onecolumn,final,openany} %ckm +\ProcessOptions + +\def\@submityear{\number\the\year} %ckm +\def\keywords#1{\gdef\@keywords{#1}} %ckm +\def\categories#1{\gdef\@categories{#1}} %ckm + +\input{size1\@ptsize.clo} +\setlength\lineskip{1\p@} +\setlength\normallineskip{1\p@} +\renewcommand\baselinestretch{} +%ckm \setlength\parskip{0\p@ \@plus \p@} +\setlength\parskip{5\p@ \@plus \p@} +\@lowpenalty 51 +\@medpenalty 151 +\@highpenalty 301 +\setcounter{topnumber}{2} +\renewcommand\topfraction{.7} +\setcounter{bottomnumber}{1} +\renewcommand\bottomfraction{.3} +\setcounter{totalnumber}{3} +\renewcommand\textfraction{.2} +\renewcommand\floatpagefraction{.5} +\setcounter{dbltopnumber}{2} +\renewcommand\dbltopfraction{.7} +\renewcommand\dblfloatpagefraction{.5} +\if@twoside + \def\ps@headings{% + \let\@oddfoot\@empty\let\@evenfoot\@empty + \def\@evenhead{\thepage\hfil\slshape\leftmark}% + \def\@oddhead{{\slshape\rightmark}\hfil\thepage}% + \let\@mkboth\markboth + \def\chaptermark##1{% + \markboth {\MakeUppercase{% + \ifnum \c@secnumdepth >\m@ne + \@chapapp\ \thechapter. \ % + \fi + ##1}}{}}% + \def\sectionmark##1{% + \markright {\MakeUppercase{% + \ifnum \c@secnumdepth >\z@ + \thesection. \ % + \fi + ##1}}}} +\else + \def\ps@headings{% + \let\@oddfoot\@empty + \def\@oddhead{{\slshape\rightmark}\hfil\thepage}% + \let\@mkboth\markboth + \def\chaptermark##1{% +% \markright {\MakeUppercase{% + \markright {{% %ckm uppercase removed + \ifnum \c@secnumdepth >\m@ne +% \@chapapp\ \thechapter. \ % + \thechapter. \ % %ckm 'Chapter' removed + \fi + ##1}}}} +\fi +\def\ps@myheadings{% + \let\@oddfoot\@empty\let\@evenfoot\@empty + \def\@evenhead{\thepage\hfil\slshape\leftmark}% + \def\@oddhead{{\slshape\rightmark}\hfil\thepage}% + \let\@mkboth\@gobbletwo + \let\chaptermark\@gobble + \let\sectionmark\@gobble + } + \if@titlepage + \newcommand\maketitle{ + \pagenumbering{roman} %ckm + \refstepcounter{part} %ckm + \begin{titlepage}% + \let\footnotesize\small + \let\footnoterule\relax + \let \footnote \thanks +%ckm \null\vfil + \null +%ckm \vskip 60\p@ + \vskip 48\p@ + \begin{center}% +%ckm {\LARGE \@title \par}% + {\Large\bf + \parbox{8cm}{ %ckm + \begin{center}\@title\end{center}} \par}% +%ckm \vskip 3em% + \vskip 0.8em% + {\large +%ckm \lineskip .75em% + \lineskip -0.8em% + \begin{tabular}[t]{c}% + \@author + \end{tabular}\par}% + \vskip 1.5em% +%ckm {\large Draft \@date \par}% % Set date in \large size. +%ckm \vfil\null +\vfill + {\it This report is submitted as partial fulfilment of\\ + the requirements for the Software Engineering Programmme of the\\ + School of Computer Science and Software Engineering,\\ + The University of Western Australia,\\ + \@submityear} + \end{center} +%ckm \par +%ckm \@thanks + \end{titlepage}% + \refstepcounter{page} %ckm + \setcounter{footnote}{0}% + \global\let\thanks\relax + \global\let\maketitle\relax + \global\let\@thanks\@empty + \global\let\@author\@empty + \global\let\@date\@empty + \global\let\@title\@empty + \global\let\title\relax + \global\let\author\relax + \global\let\date\relax + \global\let\and\relax +} +\else +\newcommand\maketitle{\par + \begingroup + \renewcommand\thefootnote{\@fnsymbol\c@footnote}% + \def\@makefnmark{\rlap{\@textsuperscript{\normalfont\@thefnmark}}}% + \long\def\@makefntext##1{\parindent 1em\noindent + \hb@xt@1.8em{% + \hss\@textsuperscript{\normalfont\@thefnmark}}##1}% + \if@twocolumn + \ifnum \col@number=\@ne + \@maketitle + \else + \twocolumn[\@maketitle]% + \fi + \else + \newpage + \global\@topnum\z@ % Prevents figures from going at top of page. + \@maketitle + \fi + \thispagestyle{plain}\@thanks + \endgroup + \setcounter{footnote}{0}% + \global\let\thanks\relax + \global\let\maketitle\relax + \global\let\@maketitle\relax + \global\let\@thanks\@empty + \global\let\@author\@empty + \global\let\@date\@empty + \global\let\@title\@empty + \global\let\title\relax + \global\let\author\relax + \global\let\date\relax + \global\let\and\relax +} +\def\@maketitle{% + \newpage + \null + \vskip 2em% + \begin{center}% + \let \footnote \thanks + {\LARGE \@title \par}% + \vskip 1.5em% + {\large + \lineskip .5em% + \begin{tabular}[t]{c}% + \@author + \end{tabular}\par}% + \vskip 1em% + {\large \@date}% + \end{center}% + \par + \vskip 1.5em} +\fi +\newcommand*\chaptermark[1]{} +\setcounter{secnumdepth}{2} +\newcounter {part} +\newcounter {chapter} +\newcounter {section}[chapter] +\newcounter {subsection}[section] +\newcounter {subsubsection}[subsection] +\newcounter {paragraph}[subsubsection] +\newcounter {subparagraph}[paragraph] +\renewcommand \thepart {\@Roman\c@part} +\renewcommand \thechapter {\@arabic\c@chapter} +\renewcommand \thesection {\thechapter.\@arabic\c@section} +\renewcommand\thesubsection {\thesection.\@arabic\c@subsection} +\renewcommand\thesubsubsection{\thesubsection .\@arabic\c@subsubsection} +\renewcommand\theparagraph {\thesubsubsection.\@arabic\c@paragraph} +\renewcommand\thesubparagraph {\theparagraph.\@arabic\c@subparagraph} +\newcommand\@chapapp{\chaptername} +\newcommand\part{% + \if@openright + \cleardoublepage + \else + \clearpage + \fi + \thispagestyle{plain}% + \if@twocolumn + \onecolumn + \@tempswatrue + \else + \@tempswafalse + \fi + \null\vfil + \secdef\@part\@spart} + +\def\@part[#1]#2{% + \ifnum \c@secnumdepth >-2\relax + \refstepcounter{part}% + \addcontentsline{toc}{part}{\thepart\hspace{1em}#1}% + \else + \addcontentsline{toc}{part}{#1}% + \fi + \markboth{}{}% + {\centering + \interlinepenalty \@M + \normalfont + \ifnum \c@secnumdepth >-2\relax + \huge\bfseries \partname~\thepart + \par + \vskip 20\p@ + \fi + \Huge \bfseries #2\par}% + \@endpart} +\def\@spart#1{% + {\centering + \interlinepenalty \@M + \normalfont + \Huge \bfseries #1\par}% + \@endpart} +\def\@endpart{\vfil\newpage + \if@twoside + \null + \thispagestyle{empty}% + \newpage + \fi + \if@tempswa + \twocolumn + \fi} +\newcommand\chapter{\if@openright\cleardoublepage\else\clearpage\fi + \thispagestyle{plain}% + \global\@topnum\z@ + \@afterindentfalse + \secdef\@chapter\@schapter} +\def\@chapter[#1]#2{\ifnum \c@secnumdepth >\m@ne + \refstepcounter{chapter}% + \typeout{\@chapapp\space\thechapter.}% + \addcontentsline{toc}{chapter}% + {\protect\numberline{\thechapter}#1}% + \else + \addcontentsline{toc}{chapter}{#1}% + \fi + \chaptermark{#1}% + \addtocontents{lof}{\protect\addvspace{10\p@}}% + \addtocontents{lot}{\protect\addvspace{10\p@}}% + \if@twocolumn + \@topnewpage[\@makechapterhead{#2}]% + \else + \@makechapterhead{#2}% + \@afterheading + \fi} +\def\@makechapterhead#1{% + \ifnum\c@part=\@ne %ckm + \ifnum\c@chapter=\@ne %ckm + \pagenumbering{arabic} %ckm + \fi %ckm + \fi %ckm +%ckm \vspace*{50\p@}% + \vspace*{-30\p@}% + {\parindent \z@ \raggedright \normalfont %ckm? + \ifnum \c@secnumdepth >\m@ne %ckm? +%ckm \huge\bfseries \@chapapp\space \thechapter + \large \MakeUppercase{\@chapapp}\space \thechapter + \par\nobreak + \vskip 20\p@ %ckm + \fi + \interlinepenalty\@M +%ckm \Huge \bfseries #1\par\nobreak + \Huge #1\par\nobreak +%ckm \vskip 40\p@ + \vskip 80\p@ + }} +\def\@schapter#1{\if@twocolumn + \@topnewpage[\@makeschapterhead{#1}]% + \else + \@makeschapterhead{#1}% + \@afterheading + \fi} +\def\@makeschapterhead#1{% + \vspace*{-15\p@}% %ckm + {\parindent \z@ \raggedright + \normalfont + \interlinepenalty\@M +%ckm \Huge \bfseries #1\par\nobreak + \Huge #1\par\nobreak + \vskip 40\p@ + }} +\newcommand\section{\@startsection {section}{1}{\z@}% + {-3.5ex \@plus -1ex \@minus -.2ex}% + {2.3ex \@plus.2ex}% +%ckm {\normalfont\Large\bfseries}} + {\normalfont\Large}} +\newcommand\subsection{\@startsection{subsection}{2}{\z@}% + {-3.25ex\@plus -1ex \@minus -.2ex}% + {1.5ex \@plus .2ex}% +%ckm {\normalfont\large\bfseries}} + {\normalfont\large}} +\newcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% + {-3.25ex\@plus -1ex \@minus -.2ex}% + {1.5ex \@plus .2ex}% +%ckm {\normalfont\normalsize\bfseries}} + {\normalfont\normalsize}} +\newcommand\paragraph{\@startsection{paragraph}{4}{\z@}% + {3.25ex \@plus1ex \@minus.2ex}% + {-1em}% + {\normalfont\normalsize\bfseries}} +\newcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% + {3.25ex \@plus1ex \@minus .2ex}% + {-1em}% + {\normalfont\normalsize\bfseries}} +\if@twocolumn + \setlength\leftmargini {2em} +\else + \setlength\leftmargini {2.5em} +\fi +\leftmargin \leftmargini +\setlength\leftmarginii {2.2em} +\setlength\leftmarginiii {1.87em} +\setlength\leftmarginiv {1.7em} +\if@twocolumn + \setlength\leftmarginv {.5em} + \setlength\leftmarginvi {.5em} +\else + \setlength\leftmarginv {1em} + \setlength\leftmarginvi {1em} +\fi +\setlength \labelsep {.5em} +\setlength \labelwidth{\leftmargini} +\addtolength\labelwidth{-\labelsep} +\@beginparpenalty -\@lowpenalty +\@endparpenalty -\@lowpenalty +\@itempenalty -\@lowpenalty +\renewcommand\theenumi{\@arabic\c@enumi} +\renewcommand\theenumii{\@alph\c@enumii} +\renewcommand\theenumiii{\@roman\c@enumiii} +\renewcommand\theenumiv{\@Alph\c@enumiv} +\newcommand\labelenumi{\theenumi.} +\newcommand\labelenumii{(\theenumii)} +\newcommand\labelenumiii{\theenumiii.} +\newcommand\labelenumiv{\theenumiv.} +\renewcommand\p@enumii{\theenumi} +\renewcommand\p@enumiii{\theenumi(\theenumii)} +\renewcommand\p@enumiv{\p@enumiii\theenumiii} +\newcommand\labelitemi{\textbullet} +\newcommand\labelitemii{\normalfont\bfseries \textendash} +\newcommand\labelitemiii{\textasteriskcentered} +\newcommand\labelitemiv{\textperiodcentered} +\newenvironment{description} + {\list{}{\labelwidth\z@ \itemindent-\leftmargin + \let\makelabel\descriptionlabel}} + {\endlist} +\newcommand*\descriptionlabel[1]{\hspace\labelsep + \normalfont\bfseries #1} +%\if@titlepage +% \newenvironment{abstract}{% +% \titlepage +%%ckm \null\vfil +%%ckm \null +%%ckm \@beginparpenalty\@lowpenalty +%%ckm +% \chapter*{\abstractname}% +%%ckm \begin{center}% +%%ckm \bfseries \abstractname +%%ckm \@endparpenalty\@M +%%ckm \end{center} +% }% +% {\par\vfil\null +% \vfill %ckm +% \noindent %ckm +% {\bf Keywords:} \@keywords \\ %ckm +% {\bf CR Categories:} \@categories %ckm +%\endtitlepage} +%\else +% \newenvironment{abstract}{% +% \if@twocolumn +% \section*{\abstractname}% +% \else +% \small +% \begin{center}% +% {\bfseries \abstractname\vspace{-.5em}\vspace{\z@}}% +% \end{center}% +% \quotation +% \fi} +% {\if@twocolumn\else\endquotation\fi} +%\fi + +%ckm next two + +\newenvironment{abstract} + {\chapter*{Abstract}} + {\vfill %ckm + \noindent %ckm + {\bf Keywords:} \@keywords \\ %ckm + {\bf CR Categories:} \@categories %ckm + \addcontentsline{toc}{chapter}{Abstract} + } + +\newenvironment{acknowledgements} + {\chapter*{Acknowledgements}} + {\addcontentsline{toc}{chapter}{Acknowledgements}} + +\newenvironment{verse} + {\let\\\@centercr + \list{}{\itemsep \z@ + \itemindent -1.5em% + \listparindent\itemindent + \rightmargin \leftmargin + \advance\leftmargin 1.5em}% + \item\relax} + {\endlist} +\newenvironment{quotation} + {\list{}{\listparindent 1.5em% + \itemindent \listparindent + \rightmargin \leftmargin + \parsep \z@ \@plus\p@}% + \item\relax} + {\endlist} +\newenvironment{quote} + {\list{}{\rightmargin\leftmargin}% + \item\relax} + {\endlist} +\if@compatibility +\newenvironment{titlepage} + {% + \if@twocolumn + \@restonecoltrue\onecolumn + \else + \@restonecolfalse\newpage + \fi + \thispagestyle{empty}% + \setcounter{page}\z@ + }% + {\if@restonecol\twocolumn \else \newpage \fi + } +\else +\newenvironment{titlepage} + {% + \if@twocolumn + \@restonecoltrue\onecolumn + \else + \@restonecolfalse\newpage + \fi + \thispagestyle{empty}% + \setcounter{page}\@ne + }% + {\if@restonecol\twocolumn \else \newpage \fi + \if@twoside\else + \setcounter{page}\@ne + \fi + } +\fi +\newcommand\appendix{\par + \refstepcounter{part} %ckm + \setcounter{chapter}{0}% + \setcounter{section}{0}% + \gdef\@chapapp{\appendixname}% + \gdef\thechapter{\@Alph\c@chapter}} + +\setlength\arraycolsep{5\p@} +\setlength\tabcolsep{6\p@} +\setlength\arrayrulewidth{.4\p@} +\setlength\doublerulesep{2\p@} +\setlength\tabbingsep{\labelsep} +\skip\@mpfootins = \skip\footins +\setlength\fboxsep{3\p@} +\setlength\fboxrule{.4\p@} +\@addtoreset {equation}{chapter} +\renewcommand\theequation + {\ifnum \c@chapter>\z@ \thechapter.\fi \@arabic\c@equation} +\newcounter{figure}[chapter] +\renewcommand \thefigure + {\ifnum \c@chapter>\z@ \thechapter.\fi \@arabic\c@figure} +\def\fps@figure{tbp} +\def\ftype@figure{1} +\def\ext@figure{lof} +\def\fnum@figure{\figurename~\thefigure} +\newenvironment{figure} + {\@float{figure}} + {\end@float} +\newenvironment{figure*} + {\@dblfloat{figure}} + {\end@dblfloat} +\newcounter{table}[chapter] +\renewcommand \thetable + {\ifnum \c@chapter>\z@ \thechapter.\fi \@arabic\c@table} +\def\fps@table{tbp} +\def\ftype@table{2} +\def\ext@table{lot} +\def\fnum@table{\tablename~\thetable} +\newenvironment{table} + {\@float{table}} + {\end@float} +\newenvironment{table*} + {\@dblfloat{table}} + {\end@dblfloat} +\newlength\abovecaptionskip +\newlength\belowcaptionskip +\setlength\abovecaptionskip{10\p@} +\setlength\belowcaptionskip{0\p@} +\long\def\@makecaption#1#2{% + \vskip\abovecaptionskip + \sbox\@tempboxa{#1: #2}% + \ifdim \wd\@tempboxa >\hsize + #1: #2\par + \else + \global \@minipagefalse + \hb@xt@\hsize{\hfil\box\@tempboxa\hfil}% + \fi + \vskip\belowcaptionskip} +\DeclareOldFontCommand{\rm}{\normalfont\rmfamily}{\mathrm} +\DeclareOldFontCommand{\sf}{\normalfont\sffamily}{\mathsf} +\DeclareOldFontCommand{\tt}{\normalfont\ttfamily}{\mathtt} +\DeclareOldFontCommand{\bf}{\normalfont\bfseries}{\mathbf} +\DeclareOldFontCommand{\it}{\normalfont\itshape}{\mathit} +\DeclareOldFontCommand{\sl}{\normalfont\slshape}{\@nomath\sl} +\DeclareOldFontCommand{\sc}{\normalfont\scshape}{\@nomath\sc} +\DeclareRobustCommand*\cal{\@fontswitch\relax\mathcal} +\DeclareRobustCommand*\mit{\@fontswitch\relax\mathnormal} +\newcommand\@pnumwidth{1.55em} +\newcommand\@tocrmarg{2.55em} +\newcommand\@dotsep{4.5} +\setcounter{tocdepth}{2} +\newcommand\tableofcontents{% + \if@twocolumn + \@restonecoltrue\onecolumn + \else + \@restonecolfalse + \fi + \chapter*{\contentsname + \@mkboth{% + \MakeUppercase\contentsname}{\MakeUppercase\contentsname}}% + \@starttoc{toc}% + \if@restonecol\twocolumn\fi + } +\newcommand*\l@part[2]{% + \ifnum \c@tocdepth >-2\relax + \addpenalty{-\@highpenalty}% + \addvspace{2.25em \@plus\p@}% + \begingroup + \parindent \z@ \rightskip \@pnumwidth + \parfillskip -\@pnumwidth + {\leavevmode + \large \bfseries #1\hfil \hb@xt@\@pnumwidth{\hss #2}}\par + \nobreak + \global\@nobreaktrue + \everypar{\global\@nobreakfalse\everypar{}}% + \endgroup + \fi} +\newcommand*\l@chapter[2]{% + \ifnum \c@tocdepth >\m@ne + \addpenalty{-\@highpenalty}% + \vskip 1.0em \@plus\p@ + \setlength\@tempdima{1.5em}% + \begingroup + \parindent \z@ \rightskip \@pnumwidth + \parfillskip -\@pnumwidth + \leavevmode \bfseries + \advance\leftskip\@tempdima + \hskip -\leftskip + #1\nobreak\hfil \nobreak\hb@xt@\@pnumwidth{\hss #2}\par + \penalty\@highpenalty + \endgroup + \fi} +\newcommand*\l@section{\@dottedtocline{1}{1.5em}{2.3em}} +\newcommand*\l@subsection{\@dottedtocline{2}{3.8em}{3.2em}} +\newcommand*\l@subsubsection{\@dottedtocline{3}{7.0em}{4.1em}} +\newcommand*\l@paragraph{\@dottedtocline{4}{10em}{5em}} +\newcommand*\l@subparagraph{\@dottedtocline{5}{12em}{6em}} +\newcommand\listoffigures{% + \if@twocolumn + \@restonecoltrue\onecolumn + \else + \@restonecolfalse + \fi + \chapter*{\listfigurename + \@mkboth{\MakeUppercase\listfigurename}% + {\MakeUppercase\listfigurename}}% + \@starttoc{lof}% + \if@restonecol\twocolumn\fi + } +\newcommand*\l@figure{\@dottedtocline{1}{1.5em}{2.3em}} +\newcommand\listoftables{% + \if@twocolumn + \@restonecoltrue\onecolumn + \else + \@restonecolfalse + \fi + \chapter*{\listtablename + \@mkboth{% + \MakeUppercase\listtablename}{\MakeUppercase\listtablename}}% + \@starttoc{lot}% + \if@restonecol\twocolumn\fi + } +\let\l@table\l@figure +\newdimen\bibindent +\setlength\bibindent{1.5em} +\newenvironment{thebibliography}[1] + {\chapter*{\bibname + \@mkboth{\MakeUppercase\bibname}{\MakeUppercase\bibname}}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}}% + \sloppy + \clubpenalty4000 + \@clubpenalty \clubpenalty + \widowpenalty4000% + \sfcode`\.\@m} + {\def\@noitemerr + {\@latex@warning{Empty `thebibliography' environment}}% + \endlist} +\newcommand\newblock{\hskip .11em\@plus.33em\@minus.07em} +\let\@openbib@code\@empty +\newenvironment{theindex} + {\if@twocolumn + \@restonecolfalse + \else + \@restonecoltrue + \fi + \columnseprule \z@ + \columnsep 35\p@ + \twocolumn[\@makeschapterhead{\indexname}]% + \@mkboth{\MakeUppercase\indexname}% + {\MakeUppercase\indexname}% + \thispagestyle{plain}\parindent\z@ + \parskip\z@ \@plus .3\p@\relax + \let\item\@idxitem} + {\if@restonecol\onecolumn\else\clearpage\fi} +\newcommand\@idxitem{\par\hangindent 40\p@} +\newcommand\subitem{\@idxitem \hspace*{20\p@}} +\newcommand\subsubitem{\@idxitem \hspace*{30\p@}} +\newcommand\indexspace{\par \vskip 10\p@ \@plus5\p@ \@minus3\p@\relax} +\renewcommand\footnoterule{% + \kern-3\p@ + \hrule\@width.4\columnwidth + \kern2.6\p@} +\@addtoreset{footnote}{chapter} +\newcommand\@makefntext[1]{% + \parindent 1em% + \noindent + \hb@xt@1.8em{\hss\@makefnmark}#1} +\newcommand\contentsname{Contents} +\newcommand\listfigurename{List of Figures} +\newcommand\listtablename{List of Tables} +\newcommand\bibname{Bibliography} +\newcommand\indexname{Index} +\newcommand\figurename{Figure} +\newcommand\tablename{Table} +\newcommand\partname{Part} +\newcommand\chaptername{Chapter} +\newcommand\appendixname{Appendix} +\newcommand\abstractname{Abstract} +\def\today{\ifcase\month\or + January\or February\or March\or April\or May\or June\or + July\or August\or September\or October\or November\or December\fi + \space\number\day, \number\year} +\setlength\columnsep{10\p@} +\setlength\columnseprule{0\p@} +\pagestyle{plain} +\pagenumbering{arabic} +\if@twoside +\else + \raggedbottom +\fi +\if@twocolumn + \twocolumn + \sloppy + \flushbottom +\else + \onecolumn +\fi + +\addtolength{\textwidth}{21.4pt} %ckm same width as cshonours.sty +\endinput +%% +%% End of file `report.cls'. diff --git a/davidfinal.pdf b/davidfinal.pdf new file mode 100644 index 0000000..51fc408 Binary files /dev/null and b/davidfinal.pdf differ diff --git a/davidfinal.tex b/davidfinal.tex new file mode 100644 index 0000000..3e5367e --- /dev/null +++ b/davidfinal.tex @@ -0,0 +1,615 @@ +\documentclass[a4paper,10pt]{cshonours} +\bibliographystyle{acm} +\usepackage[utf8]{inputenc} +\usepackage{hyperref} +\usepackage{graphicx} +\usepackage{lastpage} +\usepackage{fancyhdr} +%\usepackage{listing} +\usepackage{subcaption} +\usepackage{amsmath} +\usepackage{amssymb} +\usepackage{amsthm} +\usepackage{minted} +\pagestyle{fancyplain} + +%opening +\title{Precision in vector documents: a spatial approach} +\author{David Gow} + +\begin{document} +\cfoot{} +\lfoot{\thepage\ of \pageref{LastPage}} +\rfoot{DRAFT} +\rhead{David Gow (20513694)} +\lhead{\today} + +\maketitle + +\tableofcontents + +\chapter{Introduction} + +Documents are an important part of day-to-day life: we use them for business and pleasure, +to inform and entertain. We often use images or diagrams to illustrate our ideas, and to convey +spatial or visual information. + +On the printed page, there is a practical limit to the size and resolution of these images. +In order to store, for example, maps of large areas with fine detail, we resort to an atlas: +splitting the map up into several pages, each of which covers a different part of the map. + +With the advent of computers, we can begin to alleviate these problems. The fixed size and resolution +of the screen is worked around by having the screen be a \emph{viewport} into a larger document, letting +the document be \emph{panned} (translated laterally) and \emph{zoomed} (scaled to a particular magnification). + +However, limits in the range and precision of the numbers used to store and manipulate documents +artificially restrict the size and zoom-level of documents. While changing the numeric types used +can solve these issues, here we investigate the use of a quadtree to take advantage of the spatial +nature of the data. This is akin to maintaining the atlas of several different pages with different views +of the map, but with the advantage of greater ease-of-use and continuity. + +\chapter{Background} + +\section{Rendering} + +Computer graphics comes in two forms: bit-mapped (or raster) graphics, which is defined by an array of pixel colours; +and \emph{vector} graphics, defined by mathematical descriptions of objects. Bit-mapped graphics are well suited to photographs +and match how cameras, printers and monitors work. + + +\begin{figure}[h] + \centering \includegraphics[width=0.8\linewidth]{figures/vectorraster_example} + \caption{\label{vectorraster}A circle as a vector image and a $32 \times 32$ pixel raster image} +\end{figure} + + +However, bitmap devices do not handle zooming beyond their ``native'' resolution (the resolution where one document pixel maps +to one display pixel), exhibiting an artefact called pixelation (see Figure \ref{vectorraster}) where the pixel structure becomes evident. Attempts to use +interpolation to hide this effect are never entirely successful, and sharp edges, such as those found in text and diagrams, are particularly affected. + +Vector graphics avoid many of these problems: the representation is independent of the output resolution, and rather +an abstract description of what is being rendered, typically as a combination of simple geometric shapes like lines, +arcs and glyphs. + +As existing displays (and printers) are bit-mapped devices, vector documents must be \emph{rasterized} into a bitmap at +a given resolution. The resulting bitmap is then an approximation of the vector image +at that resolution. This bitmap is then displayed or printed. + +% Project specific line +We will discuss the use of vector graphics, as they lend themselves more naturally to scaling, +though many of the techniques will also apply to raster graphics. Indeed, the use of quadtrees +to compress bitmapped data is well established\cite{salomon2007data}, and the view-reparenting +techniques have been used to facilitate an infinite zoom into a (procedurally generated) document\cite{munroe2014pixels}. + +\subsection{Rasterizing Vector Graphics} + +Before an vector document can be rasterized, the co-ordinates of any shapes must +be transformed into \emph{screen space} or \emph{viewport space}\cite{blinn1992trip}. +On a typical display, many of these screen-space coordinates require very little precision or range. +However, the co-ordinate transform must take care to ensure that precision is preserved during this transform. + +After this transformation, the image is decomposed into its separate shapes, which are rasterized +and then composited together. +Most graphics formats support Porter-Duff compositing\cite{porter1984compositing}. +Porter-Duff compositing gives each element (typically a pixel) a ``coverage'' value, +denoted $\alpha$ which represents the contribution of that element to the final scene. +Completely transparent elements would have an $\alpha$ value of $0$, and completely opaque +elements have an $\alpha$ of $1$. This permits arbitrary shapes to be layered over one another +in the raster domain, while retaining soft-edges. + +The rasterization process may then proceed on one object (or shape) at a time. There are special algorithms for rasterizing +different shapes. + +\begin{description} + \item[Line Segment] + Straight lines between two points are easily rasterized using Bresenham's algorithm\cite{bresenham1965algorithm}. + Bresenham's algorithm draws a pixel for every point along the \emph{long} axis of the line, moving along the short + axis when the error exceeds $\frac{1}{2}$ a pixel. + + Bresenham's algorithm only operates on lines whose endpoints lie on integer pixel coordinates. Due to this, line ``clipping'' + may be performed to find endpoints of the line segment such that the entire line will be on-screen. However, if line clipping is + performed na\"ively without also setting the error accumulator correctly, the line's slope will be altered slightly, becoming dependent + on the viewport. + + \item[B\'ezier Curve] + A B\'ezier curve is a smooth (i.e.\ infinitely differentiable) curve between two points, represented by a Bernstein polynomial. + The coefficients of this Bernstein polynomial are known as the ``control points.'' + + B\'ezier curves are typically rasterized using De Casteljau's algorithm\cite{foley1996computer} + Line Segments are a first-order B\'ezier curve. + +\end{description} + + +%There are special algorithms +%for rendering lines\cite{bresenham1965algorithm}, triangles\cite{giesen2013triangle}, polygons\cite{pineda1988parallel} and B\'ezier +%Curves\cite{goldman_thefractal}. + +\subsection{GPU Rendering} +While traditionally, rasterization was done entirely in software, modern computers and mobile devices have hardware support for rasterizing +lines and triangles designed for use rendering 3D scenes. This hardware is usually programmed with an +API like \texttt{OpenGL}\cite{openglspec}. + +More complex shapes like B\'ezier curves can be rendered by combining the use of bitmapped textures (possibly using signed-distance +fields\cite{leymarie1992fast}\cite{frisken2000adaptively}\cite{green2007improved}) strtched over a triangle mesh +approximating the curve's shape\cite{loop2005resolution}\cite{loop2007rendering}. + +Indeed, there are several implementations of entire vector graphics systems using OpenGL: +\begin{itemize} + \item The OpenVG standard\cite{robart2009openvg} has been implemented on top of OpenGL ES\cite{oh2007implementation}; + \item the Cairo\cite{worth2003xr} library, based around the PostScript/PDF rendering model, has the ``Glitz'' OpenGL backend\cite{nilsson2004glitz} + \item and the SVG/PostScript GPU renderer by nVidia\cite{kilgard2012gpu} as an OpenGL extension\cite{kilgard300programming}. +\end{itemize} + + +\section{Numeric formats} + +On modern computer architectures, there are two basic number formats supported: +fixed-width integers and \emph{floating-point} numbers. Typically, computers +natively support integers of up to 64 bits, capable of representing all integers +between $0$ and $2^{64} - 1$, inclusive\footnote{Most machines also support \emph{signed} integers, +which have the same cardinality as their \emph{unsigned} counterparts, but which +represent integers in the range $[-(2^{63}), 2^{63} - 1]$}. + +By introducing a fractional component (analogous to a decimal point), we can convert +integers to \emph{fixed-point} numbers, which have a more limited range, but a fixed, greater +precision. For example, a number in 4.4 fixed-point format would have four bits representing the integer +component, and four bits representing the fractional component: +\begin{equation} + \underbrace{0101}_\text{integer component}.\underbrace{1100}_\text{fractional component} = 5.75 +\end{equation} + + +Floating-point numbers\cite{goldberg1992thedesign, taocp2} are a superset of scientific notation, +originally used by the Babylonians (in base 60) perhaps as early as 1750 BC. +Each number $n$ (in a base $\beta$) consists of integers $e$ (the \emph{exponent}) and $m$ (the \emph{mantissa}) such that +\begin{equation} + n = \beta^{e} \times m_f +\end{equation} + +Both $e$ and $m$ typically have a fixed width $q$ and $p$ respectively in base $\beta$. For notational convenience, we also +represent $m$ as a fraction $m_f = \beta^{-p} m$ so $|m_f| < 1$. We further call a floating point number +\emph{normalised} if the first digit of $m$ is nonzero. The exponent $e$ is usually allowed to be +either positive or negative (either by having a sign bit, or being offset a fixed amount). The value +of a floating point number $n$ must therefore be $-\beta^{e_max} < n < \beta^{e_max}$. The smallest +possible magnitude of a normalised floating point number is $\beta^{e_min-1}$, as $m_f$ must be at least $0.1$. +Non-normalised numbers may represent $0$, and many normalised floating-point include zero in some way, too. + +The IEEE 754 standard\cite{ieee754std1985} defines several floating-point data types +which are used\footnote{Many systems implement the IEEE 754 standard's storage formats, +but do not implement arithmetic operations in accordance with this standard\cite{openglspec, ARBshaderprecision}.} by most +computer systems. The standard defines 32-bit (8-bit exponent, 23-bit mantissa, 1 sign bit) and +64-bit (11-bit exponent, 53-bit mantissa, 1 sign bit) formats\footnote{The 2008 +revision to this standard\cite{ieee754std2008} adds some additional formats, but is +less widely supported in hardware.}, which can store approximately 7 and 15 decimal digits +of precision respectively. The IEEE 754 standard also introduces an implicit $1$ bit in the most +significant place of the mantissa when the exponent is not $e_min$. + +Floating-point numbers behave quite differently to integers or fixed-point numbers, as +the representable numbers are not evenly distributed. Large numbers are stored to a lesser +precision than numbers close to zero. This can present problems in documents when zooming in +on objects far from the origin. Furthermore, due to the limited precision, and the different +``alignment'' of operands in arithmetic, several algebraic properties of rings we take for +granted in the integers do not exist, including the property of assosciativity\cite{taocp2}. + +IEEE floating-point has some interesting features as well, including values for negative zero, +positive and negative infinity, the ``Not a Number'' (NaN) value and \emph{subnormal} values, which +trade precision for range when dealing with very small numbers by not normalising +numbers when the exponent is $e_min$. Indeed, with these values, +IEEE 754 floating-point equality does not form an equivalence relation, which can cause issues +when not considered carefully\cite{goldberg1991whatevery}. + +There also exist formats for storing numbers with arbitrary precising and/or range. +Some programming languages support ``big integer''\cite{java_bigint} types which can +represent any integer that can fit in the system's memory. Similarly, there are +arbitrary-precision floating-point data types\cite{java_bigdecimal}\cite{boost_multiprecision} +which can represent any number of the form +\begin{equation} + \frac{n}{2^d} \; \; \; \; n,d \in \mathbb{Z} % This spacing is horrible, and I should be ashamed. +\end{equation} +These types are typically built from several native data types such as integers and floats, +paired with custom routines implementing arithmetic primitives.\cite{priest1991algorithms} +Operations on these types, therefore, are usually slower than those performed on native types. + +Pairs of integers $(a \in \mathbb{Z},b \in \mathbb{Z}\setminus 0)$ can be used to represent rationals. This allows +values such as $\frac{1}{3}$ to be represented exactly, whereas in fixed or floating-point formats, +this would have a recurring representation: +\begin{equation} + \underbrace{0}_\text{integer part} . \underbrace{01}_\text{recurring part} 01 \; \; 01 \; \; 01 \dots +\end{equation} +Whereas with a rational type, this is simply $\frac{1}{3}$. +Rationals do not have a unique representation for each value, typically the reduced fraction is used +as a characteristic element. + +While traditionally, GPUs have supported some approximation of IEEE 754's 32-bit floats, +modern graphics processors also support 16-bit\cite{nv_half_float} and 64-bit\cite{arb_gpu_shader_fp64} +IEEE floats, though some features of IEEE floats, like denormals and NaNs are not always supported. +Note, however, that some parts of the GPU are not able to use all formats, +so precision will likely be truncated at some point before display. +Higher precision numeric types can be implemented or used on the GPU, but are +slow.\cite{emmart2010high} + + +\section{Document Formats} + +Most existing document formats --- such as the venerable PostScript and PDF --- are, however, designed to imitate +existing paper documents, largely to allow for easy printing. In order to truly take advantage of the possibilities operating in the digital +domain opens up to us, we must look to new formats. + +Formats such as \texttt{HTML} allow for a greater scope of interactivity and for a more data-driven model, allowing +the content of the document to be explored in ways that perhaps the author had not anticipated.\cite{hayes2012pixels} +However, these data-driven formats typically do not support fixed layouts, and the display differs from renderer to +renderer. + +\subsection{A Taxonomy of Document formats} + +The process of creating and displaying a document is a rather universal one (\ref{documenttimeline}), though +different document formats approach it slightly differently. A document often begins as raw content: text and images +(be they raster or vector) and it must end up as a stream of photons flying towards the reader's eyes. + +\begin{figure} + \label{documenttimeline} + \centering \includegraphics[width=0.8\linewidth]{figures/documenttimeline} + \caption{\label{doclifecycle}The lifecycle of a document} +\end{figure} + +There are two fundamental stages (as shown in Figure \ref{doclifecycle}) by which all documents --- digital or otherwise --- are produced and displayed: +\emph{layout} and \emph{rendering}. The \emph{layout} stage is where the positions and sizes of text and other graphics are +determined. The text will be \emph{flowed} around graphics, the positions of individual glyphs will be placed, ensuring +that there is no undesired overlap and that everything will fit on the page or screen. + +The \emph{display} stage actually produces the final output, whether as ink on paper or pixels on a computer monitor. +Each graphical element is rasterized and composited into a single image of the target resolution. + + +Different document formats cover documents in different stages of this project. Bitmapped images, +for example, would represent the output of the final stage of the process, whereas markup languages typically specify +a document which has not yet been processed, ready for the layout stage. + +Furthermore, some document formats treat the document as a program, written in +a (usually Turing complete) document language with instructions which emit shapes to be displayed. These shapes are either displayed +immediately, as in PostScript, or stored in another file, such as with \TeX or \LaTeX, which emit a \texttt{DVI} file. Most other +forms of document use a \emph{Document Object Model}, being a list or tree of objects to be rendered. \texttt{DVI}, \texttt{PDF}, +\texttt{HTML}\footnote{Some of these formats --- most notably \texttt{HTML} --- implement a scripting lanugage such as JavaScript, +which permit the DOM to be modified while the document is being viewed.} and SVG\cite{svg2011-1.1}. Of these, only \texttt{HTML} and \TeX typically +store documents in pre-layout stages, whereas even Turing complete document formats such as PostScript typically encode documents +which already have their elements placed. + +\begin{description} + \item[\TeX \, and \LaTeX] + Donald Knuth's typesetting language \TeX \, is one of the older computer typesetting systems, originally conceived in 1977\cite{texdraft}. + It implements a Turing-complete language and is human-readable and writable, and is still popular + due to its excellent support for typesetting mathematics. + \TeX only implements the ``layout'' stage of document display, and produces a typeset file, + traditionally in \texttt{DVI} format, though modern implementations will often target \texttt{PDF} instead. + + This document was prepared in \LaTeXe. + + \item[DVI] + \TeX \, traditionally outputs to the \texttt{DVI} (``DeVice Independent'') format: a binary format which consists of a + simple stack machine with instructions for drawing glyphs and curves\cite{fuchs1982theformat}. + + A \texttt{DVI} file is a representation of a document which has been typeset, and \texttt{DVI} + viewers will rasterize this for display or printing, or convert it to another similar format like PostScript + to be rasterized. + + \item[HTML] + The Hypertext Markup Language (HTML)\cite{html2rfc} is the widely used document format which underpins the + world wide web. In order for web pages to adapt appropriately to different devices, the HTML format simply + defined semantic parts of a document, such as headings, phrases requiring emphasis, references to images or links + to other pages, leaving the \emph{layout} up to the browser, which would also rasterize the final document. + + The HTML format has changed significantly since its introduction, and most of the layout and styling is now controlled + by a set of style sheets in the CSS\cite{css2spec} format. + + \item[PostScript] + Much like DVI, PostScript\cite{plrm} is a stack-based format for drawing vector graphics, though unlike DVI (but like \TeX), PostScript is + text-based and Turing complete. PostScript was traditionally run on a control board in laser printers, rasterizing pages at high resolution + to be printed, though PostScript interpreters for desktop systems also exist, and are often used with printers which do not support PostScript natively.\cite{ghostscript} + + PostScript programs typically embody documents which have been typeset, though as a Turing-complete language, some layout can be performed by the document. + + \item[PDF] + Adobe's Portable Document Format (PDF)\cite{pdfref17} takes the PostScript rendering model, but does not implement a Turing-complete language. + Later versions of PDF also extend the PostScript rendering model to support translucent regions via Porter-Duff compositing\cite{porter1984compositing}. + + PDF documents represent a particular layout, and must be rasterized before display. + + \item[SVG] + Scalable Vector Graphics (SVG) is a vector graphics document format\cite{svg2011-1.1} which uses the Document Object Model. It consists of a tree of matrix transforms, + with objects such as vector paths (made up of B\'ezier curves) and text at the leaves. + +\end{description} + +\subsection{Precision in Document Formats} + +Existing document formats --- typically due to having been designed for documents printed on paper, which of course has +limited size and resolution --- use numeric types which can only represent a fixed range and precision. +While this works fine with printed pages, users reading documents on computer screens using programs +with ``zoom'' functionality are prevented from working beyond a limited scale factor, lest artefacts appear due +to issues with numeric precision. + +\TeX uses a $14.16$ bit fixed point type (implemented as a 32-bit integer type, with one sign bit and one bit used to detect overflow)\cite{beebe2007extending}. +This can represent values in the range $[-(2^{14}), 2^{14} - 1]$ with 16 binary digits of fractional precision. + +The DVI files \TeX \, produces may use ``up to'' 32-bit signed integers\cite{fuchs1982theformat} to specify the document, but there is no requirement that +implementations support the full 32-bit type. It would be permissible, for example, to have a DVI viewer support only 24-bit signed integers, though many +files which require greater range may fail to render correctly. + +PostScript\cite{plrm} supports two different numeric types: \emph{integers} and \emph{reals}, both of which are specified as strings. The interpreter's representation of numbers +is not exposed, though the representation of integers can be divined by a program by the use of bitwise operations. The PostScript specification lists some ``typical limits'' +of numeric types, though the exact limits may differ from implementation to implementation. Integers typically must fall in the range $[-2^{31}, 2^{31} - 1]$, +and reals are listed to have largest and smallest values of $\pm10^{38}$, values closest to $0$ of $\pm10^{-38}$ and approximately $8$ decimal digits of precision, +derived from the IEEE 754 single-precision floating-point specification. + +Similarly, the PDF specification\cite{pdfref17} stores \emph{integers} and \emph{reals} as strings, though in a more restricted format than PostScript. +The PDF specification gives limits for the internal representation of values. Integer limits have not changed from the PostScript specification, but numbers +representable with the \emph{real} type have been specified differently: the largest representable values are $\pm 3.403\times 10^{38}$, the smallest non-zero representable values are +$\pm1.175 \times 10^{-38}$ with approximately $5$ decimal digits of precision \emph{in the fractional part}. +\footnote{The PDF specification mistakenly leaves out the negative in the exponent here.} +Adobe's implementation of PDF uses both IEEE 754 single precision floating-point numbers and (for some calculations, and in previous versions) 16.16 bit fixed-point values. + +The SVG specification\cite{svg2011-1.1} specifies numbers as strings with a decimal representation of the number. +It is stated that a ``Conforming SVG Viewer'' must have ``all visual rendering accurate to within one device pixel to the mathematically correct result at the initial 1:1 +zoom ratio'' and that ``it is suggested that viewers attempt to keep a high degree of accuracy when zooming.'' +A ``Conforming High-Quality SVG Viewer'' must use ``double-precision floating point\footnote{Presumably the 64-bit IEEE 754 ``double'' type.}'' for computations involving +coordinate system transformations. + +\section{Quadtrees} +When viewing or processing a small part of a large document, it may be helpful to +only process --- or \emph{cull} --- parts of the document which are not on-screen. + +\begin{figure}[h] + \centering \includegraphics[width=0.4\linewidth]{figures/quadtree_example} + \caption{A simple quadtree.} +\end{figure} +The quadtree\cite{finkel1974quad}is a data structure --- one of a family of \emph{spatial} +data structures --- which recursively breaks down space into smaller subregions +which can be processed independently. Points (or other objects) are added to a single +node which (if certain criteria are met) is split into four equal-sized subregions, and +points attached to the region which contains them. + +Quadtrees have been used in computer graphics for both culling --- excluding objects in +nodes which are not visible --- and ``level of detail'', where different levels of the quadtree store +different quality versions of objects or data\cite{zerbst2004game}. +Typically the number of points in a node +exceeding a maximum triggers this split, though in our case likely the level of precision required exceeding +that supported by the data type in use. + +In this project, we will be experimenting with a form of quadtree in which each +node has its own independent coordinate system, allowing us to store some spatial +information\footnote{One bit per-coordinate, per-level of the quadtree} within the +quadtree structure, eliminating redundancy in the coordinates of nearby objects. + +Other spatial data structures exist, such as the KD-tree\cite{bentley1975multidimensional}, +which partitions the space on any axis-aligned line; or the BSP tree\cite{fuchs1980onvisible}, +which splits along an arbitrary line which need not be axis aligned. We believe, however, +that the simpler conversion from binary coordinates to the quadtree's binary split make +it a better avenue for initial research to explore. + +\chapter{\texttt{IPDF}: A Document Precision Playground} +In order to investigate the precision issues present in document formats and viewers, +we developed a document viewer \texttt{IPDF}. \texttt{IPDF} is a \texttt{C++} program +which supports rendering TrueType font outlines and a subset of the \texttt{SVG} +format. + +At its core, \texttt{IPDF} breaks documents down into a set of \emph{objects}, each +with rectangular bounds $(x, y, w, h)$ and with several \emph{types}: +\begin{enumerate} + \item \textbf{Rectangle:} A simple, axis-aligned rectangle (either filled with a solid colour or + left as an outline) covering the object bounds. + \item \textbf{Ellipse:} A filled, axis-aligned ellipse, rendered parametrically. + \item \textbf{B\'ezier Curve:} A cubic B\'ezier curve. B\'ezier curve + control points are stored relative to the coordinate system provided by the + document bounds, and several objects can share these coefficients. +\end{enumerate} + +\texttt{IPDF} can be compiled using different number representations, to allow for +comparison between not only different-precision floating point numbers, but also +arbitrary-precision types such as rationals. + +Documents in \texttt{IPDF} may be rendered either on the CPU, using a custom software +rasterizer built on the numeric types supported, or on the GPU with OpenGL 3.2 shaders, using +the GPU's default numeric representation. + +Furthermore, \texttt{IPDF} allows \texttt{SVG} files (and text rendered with TrueType fonts) to be inserted at any point and scale in +the document, allowing for the same images to be compared at different scales. + +\section{GPU Floating Point Rounding Behaviour} +While the IEEE-754 standard specifies both the format of floating-point numbers and the operations they perform. +However, the OpenGL specification\cite{openglspec}, while requiring the same basic format for single-precision floats, +does not specify the behaviour of denormals, nor requires any support for NaN or infinite values. Similarly, no support +for floating point exceptions is required, with the note that no operation should ever halt the GPU. + +However, an extension to the specification, \texttt{GL\_ARB\_shader\_precision}\cite{ARBshaderprecision} in 2010 +allows programs to require stricter precision requirements. Notably, support for infinite values is required and +maximum relative error in ULPs. + +Different GPU vendors and drivers have different rounding behaviour, and most hardware (both CPU and GPU) provide +ways of disabling support for some IEEE features to improve performance\cite{intelgpuspec, dawson2012notnormal}. + +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{figures/circles_gpu_vs_cpu/comparison.pdf} +\caption{\label{fig:circles}The edges of a unit circle viewed through bounds (x,y,w,h) = (0.0869386,0.634194,2.63295e-07,2.63295e-07)} +\end{figure} + +Many GPUs now support double-precision floating-point numbers\footnote{Some drivers, however, do not yet support this feature, including one of our test machines.} +as specified in the \texttt{GL\_ARB\_gpu\_shader\_fp64}\cite{arb_gpu_shader_fp64} OpenGL extension. +However, many of the fixed-function parts of the GPU do not support double-precision floats, +making it impractical to use them. + +To see the issues, we rendered the edge of a circle (calculated by discarding pixels with $x^2 + y^2 > 1$) on several GPUs, as well as an \texttt{x86-64} CPU, +as seen in \autoref{fig:circles}. +Of these, the nVidia GPU came closest to the CPU rendering, whereas Intel's hardware clearly performs some optimisation which produces quite different artefacts. +The diagonal distortion in the AMD rendering may be a result of different rounding across the two triangles across which the circle was rendered. +\section{Distortion and Quantisation at the limits of precision} +TODO: Fix these figures, explain properly. +\begin{figure}[h] + + \begin{subfigure}{.5\linewidth} + \includegraphics[width=\linewidth]{cpu0} + \subcaption{Intended rendering} + \end{subfigure} + \begin{subfigure}{.5\linewidth} + \includegraphics[width=\linewidth]{cpu100} + \subcaption{With artefacts} + \end{subfigure} + \caption{\label{fig:precisionerrors}Floating point errors affecting the rendering of an image} + +\end{figure} + +When trying to insert fine detail into a document using fixed-width floats, some precision is lost. In particular, the +control points of the curves making up the image get rounded to the nearest\footnote{Other rounding modes are available, +but they all suffer from similar artefacts.} representable point. \autoref{fig:precisionerrors} shows what happens when an +image is small enough to be affected by this quantisation. The grid structure becomes very apparent. + +These artefacts also become prevalent when an object is far from the origin, as more bits would be required to store the +position, so the lower order bits of the position must be discarded. As the position of the viewport and the object will share +many of the same initial digits, catastrophic cancellation\cite{goldberg1991whatevery} can occur. + +%\subsection{Big Integers} +%Computers typically operate on \emph{fixed-width} integers\footnote{The term ``machine word'' has traditionally been used +%for a CPUs default numeric type, though for historical reasons this is sometimes also used to refer to a 16-bit type, regardless +%of the preferred type of the underlying machine.} for which they have hardware adders. + +%These types are represented by $n$ bits (typically $n$ is 32 or 64), and represents the +%ring $\mathbb{Z}_n$: i.e.\ any number in the range $[0,2^{n})$ can be represented, and operations +%are performed $\mod 2^n$. +\chapter{View Reparenting and the Quadtree} +One of the important parts of document rendering is that of coordinate transforms. + +Traditionally, the document exists in its own coordinate system, $\mathbf{b}$. +We then define a coordinate system $\mathbf{v}$ to represent the view. + +To eliminate visible error due to floating point precision, we need to ensure that +any point (including control points) must be representable as a float both in the +document and in view coordinates, i.e: +\begin{enumerate} + \item have a limited magnitude, + \item be precise enough to uniquely identify a pixel on the display. +\end{enumerate} + +Despite a point not being representable with floats in one coordinate system, +it may be representable in another. We can therefore split a document up into +several coordinate systems, such that each point is completely representable. + +Similarly, the points making up the visible document need to all be representable +(to at least one pixel's worth of precision). To achieve this, we use a quadtree where +each node stores points within its bounds in its own coordinate system. Objects +which span multiple nodes are clipped, such that no points\footnote{except some +control points} lie outside the quadtree node. + +Setting aside the possibility that an object might span multiple nodes for the time +being, let's investigate how the coordinates of a point are affected by placing it +in the quadtree. + +Suppose $p = (p_x, p_y)$ is a point in a global document coordinate system, which we'll +consider the root node of our quadtree. $p_x$ and $p_y$ are represented by a finite +list of binary digits $x_0 \dots x_n$, $y_0 \dots y_n$. +Consider now the pair $(x_0, y_0)$: +\begin{align*} + x_0 &= \begin{cases} + 0 & \text{if }p_x\text{ is in the left half of }d\\ + 1 & \text{if }p_x\text{ is in the right half of }d + \end{cases} \\ + y_0 &= \begin{cases} + 0 & \text{if }p_y\text{ is in the bottom half of }d\\ + 1 & \text{if }p_y\text{ is in the top half of }d + \end{cases} +\end{align*} + +We have therefore found which child node of our quadtree contains $p$. The coordinates +of $p$ within that node are $(x_1 \dots x_n, y_1 \dots y_n)$. By the principle of mathematical +induction, we can repeat the process to move more bits from the coordinates of $p$ into the +structure of the quadtree, until the remaining coordinates may be precisely represented. + +This implies that the quadtree is equivalent to an arbitrary precision integer datatype. By reversing +the process, any point representable in the quadtree can be stored as a fixed-length bit string. + +%It is natural to treat these coordinates as being between $0$ and $1$. + +Furthermore, we can get approximations of points by inserting them into higher levels of the quadtree, +with their coordinates rounded. By then viewing the document at a certain level of the quadtree, we +then not only do not need to consider bits of precision which are not required to represent the point to +pixel resolution, we can also cull objects outside the visible nodes at that level. + +Indeed, we can guarantee that, by selecting the level of the quadtree we view such that +the view width and height lie within the range $(0.5,1]$, we can ensure that at most +four nodes need to be rendered. + + +\section{Clipping cubic B\'eziers} +In order to ensure that the quadtree maintains precision in this fashion, we need to ensure +that all objects are entirely contained within a quadtree node. This is not always the case and, +indeed, when zooming in on any object, eventually the object will span multiple quadtree nodes. + +{\bf TODO: We can show this by showing that, given $(a,b) \in \mathbb{R}, \exists $ binary fraction $c$ such that $a < c < b$.} + +We therefore need a way to subdivide objects into several objects, each of which is contained within one node. +To do this, we need to \emph{clip} the cubic B\'ezier curves from which our document is formed to a rectangle. + +Cubic B\'ezier curves are defined parametrically as two cubics: $x(t)$ and $y(t)$, with $0 \leq t \leq 1$. +We clip these to a rectangular bounding box in stages. We first find the intersections of the curve with +the clipping rectangle by finding the roots\footnote{While there is a method for solving cubics exactly\cite{cardano1545artis}, +we instead use numeric methods to avoid the need for square root operations, which cannot be done exactly +on some of the numeric types we used.} +of the cubic shifted to match the corners of the rectangle. This produces some spurious points, as it assumes the edges +of the clipping rectangle are lines with infinite extent, but this at worst introduces some minor inefficiency in the process and does +not affect the result. + +Once the values of the parameter $t$ which intersect the clipping rectangle have +been determined, the curve is split into segments. To do this, the values $0$ and $1$ +(representing the endpoints) are added to the list of intersecting $t$ values, which is then +sorted. Adjacent values $t_0$ and $t_1$ form a segment. The midpoint of that segment (with the +value $\frac{t_0 + t_1}{2}$) is evaluate and if it falls +outside the clipping rectangle, the segment is discarded. + +Finally, the segments are re-parametrised by subdividing the curve using De Casteljau's +algorithm\cite{sederberg2007cad}. By re-parameterising the curves such that $0 \leq t \leq 1$, +we ensure that the first and last coefficients have the endpoints' coodinates, and therefore +lie in the quadtree node. + +{\bf TODO: Prove that the other control points' magnitude is reduced, and try to quantify it, prove that +it will never overflow.} + +\section{Implementation Details} +\begin{itemize} + \item Store object ID ranges. + \item Pointers to children and parent. + \item Linked-list of ``overlay'' nodes for mutation. + \item Have billions of bugs. +\end{itemize} + + + +\chapter{Experimental Results} +These are all iPython-y at the moment. + +Roughly 3s/frame for GMP rationals, 16ms for Quadtree which is still slightly broken. +\section{Performance per object} + +\section{Performance per onscreen object} + +\section{Performance per zoom-level} + +\section{Stability of performance} + +\chapter{Further Work and Conclusion} +The use of spatial data structures to specify documents with arbitrary precision +has been validated as a viable alternative to the use of arbitrary precision numeric +types where an arbitrary (rather than infinite) amount of precision is needed. +Once constructed, they are faster in many circumstanced, and the structure +can also be used for culling. When the viewport moves and scales smoothly, the cost +of constructing new nodes is amortised over the movement. +Unfortunately, the mutation of the quadtree is difficult and slow, and discontinuous +movement can result in a large number of nodes needing to be created. + +Quadtree seems to be viable and is really performant. + +Loop-blinn shading. + + +\bibliography{papers} + +\end{document} diff --git a/papers.bib b/papers.bib index 362dedf..e6302ae 100644 --- a/papers.bib +++ b/papers.bib @@ -1147,3 +1147,77 @@ ISSN={0164-1239},} pages = 69, doi = "10.1016/S1571-0661(05)80215-4" } + + +% XKCD comic "pixels" +@misc{munroe2014pixels, +author={Munroe, Randall}, +title={Pixels}, +url={http://xkcd.com/1416}, +howpublished={\url{http://xkcd.com/1416/} accessed 2014-09-03}, +journal={xkcd: A webcomic of romance, sarcasm, math, and language.} +year={2014}, +month={September}, +day={3}, +date={2014-09-03}, +number={1416} +} + +% GL_ARB_shader_precision +@misc{ARBshaderprecision, +author={Kessenich, John}, +title={{GL\_ARB\_shader\_precision}}, +year={2010}, +howpublished={\url{https://www.opengl.org/registry/specs/ARB/shader_precision.txt} accessed 2014-10-17} +} + +@article{intelgpuspec, +author={Intel Corporation}, +title={{3D/Media --- 3D Pipeline (Ivy Bridge)}}, +journal={{Intel OpenSource HD Graphics Programmer's Reference Manual (PRM)}}, +year={2012}, +url={https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol2_part1.pdf}, +volume={2}, +number={1} +} + +@misc{dawson2012notnormal, +author={Dawson, Bruce}, +title={{That's Not Normal --- the Performance of Odd Floats}}, +year={2012}, +howpublished={\url{https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/} accessed 2014-10-18} +} + +# Original cubic solution +@misc{cardano1545artis, +author={Cardano, Gerolamo}, +title={Artis magnae sive de regulis agebraicis: liber unus}, +year={1545} +} + +@misc{sederberg2007cad, +author={Sederberg, T. W.}, +title={Computer Aided Geometric Design Course Notes}, +year={2007} +} + +@book{salomon2007data, + title={Data Compression: The Complete Reference}, + author={Salomon, D. and Motta, G. and Bryant, D.}, + isbn={9781846286032}, + lccn={2006931789}, + series={Molecular biology intelligence unit}, + url={http://books.google.com.au/books?id=ujnQogzx\_2EC}, + year={2007}, + publisher={Springer} +} + +@book{taocp2, + title={Seminumerical Algorithms}, + author={Knuth, Donald}, + year={1998}, + volume={2}, + series={The Art of Computer Programming}, + publisher={Addison--Wesley}, + edition={3rd} +} \ No newline at end of file