From: David Gow Date: Fri, 23 May 2014 04:03:52 +0000 (+0800) Subject: Final lit review, as submitted. X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=b6a5df93b7f37f1864c831ea541ab21893b67267;p=ipdf%2Fdocuments.git Final lit review, as submitted. --- diff --git a/LitReviewDavid.pdf b/LitReviewDavid.pdf index 5274454..9c5d4ec 100644 Binary files a/LitReviewDavid.pdf and b/LitReviewDavid.pdf differ diff --git a/LitReviewDavid.tex b/LitReviewDavid.tex index da4d5d8..5cde5c6 100644 --- a/LitReviewDavid.tex +++ b/LitReviewDavid.tex @@ -21,7 +21,7 @@ could be passed on from person to person without them ever meeting. And thus the document was born. -Traditionally, documents have been static: just marks on paper, but with the advent of computers many more possibilities open up. +Traditionally, documents have been static: just marks on rock, parchment or paper, but with the advent of computers many more possibilities open up. \section{Rendering} @@ -37,8 +37,8 @@ and match how cameras, printers and monitors work. \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 where the pixel structure becomes evident. Attempts to use +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 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 @@ -87,6 +87,7 @@ different shapes. 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. \item[B\'ezier Spline] @@ -103,16 +104,21 @@ different shapes. %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}) with polygons approximating the curve's shape\cite{loop2005resolution}\cite{loop2007rendering}. +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: OpenVG\cite{robart2009openvg} on top of OpenGL ES\cite{oh2007implementation}; -the Cairo\cite{worth2003xr} library, based around the PostScript/PDF rendering model, has the ``Glitz'' OpenGL backend\cite{nilsson2004glitz} and the SVG/PostScript GPU -renderer by nVidia\cite{kilgard2012gpu} as an OpenGL extension\cite{kilgard300programming}. +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} @@ -171,13 +177,6 @@ These types are typically built from several native data types such as integers paired with custom routines implementing arithmetic primitives.\cite{priest1991algorithms} These, therefore, are likely slower than the native types they are built on. -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. Note, however, that some parts of the GPU are only able to use some 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} - 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: @@ -188,6 +187,15 @@ 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 only able to use some 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 @@ -203,7 +211,7 @@ renderer. 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 set of photons flying towards the reader's eyes. +(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} @@ -274,7 +282,7 @@ which already have their elements placed. 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} which uses the Document Object Model. It consists of a tree of matrix transforms, + 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} @@ -307,7 +315,7 @@ representable with the \emph{real} type have been specified differently: the lar $\pm1.175 \times 10^{-38}$ with approximately $5$ decimal digits of precision \emph{in the fractional part}. 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} specifies numbers as strings with a decimal representation of the number. +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 @@ -324,11 +332,16 @@ only processs --- or \emph{cull} --- parts of the document which are not on-scre 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 --- typically the number of points in a node -exceeding a maximum, though in our case likely the level of precision required exceeding -that supported by the data type in use --- is split into four equal-sized subregions, and +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 diff --git a/ProjectProposalDavid.pdf b/ProjectProposalDavid.pdf index 64a419e..bd6e957 100644 Binary files a/ProjectProposalDavid.pdf and b/ProjectProposalDavid.pdf differ diff --git a/ProjectProposalDavid.tex b/ProjectProposalDavid.tex index ede727f..ca7acc5 100644 --- a/ProjectProposalDavid.tex +++ b/ProjectProposalDavid.tex @@ -31,7 +31,7 @@ \maketitle\hrule \begin{center} \begin{tabular}{lp{0.8\textwidth}} -\textbf{Title:} & Infinite-precision document formats\\ +\textbf{Title:} & Arbitrary-precision document formats\\ \textbf{Supervisor} & A/Prof. Tim French\\ \textbf{Project Group:} & David Gow, Samuel Moore \end{tabular} diff --git a/papers.bib b/papers.bib index 3ed374d..2a12d2f 100644 --- a/papers.bib +++ b/papers.bib @@ -20,7 +20,9 @@ title={Preliminary preliminary description of {\TeX}}, author={Knuth, Donald}, year={1977}, - howpublished={\url{http://www.saildart.org/TEXDR.AFT[1,DEK]1}} + howpublished={\url{http://www.saildart.org/TEXDR.AFT[1,DEK]1}}, + urldate={2014-05-20}, + note={Retrieved 2014-05-20} } @article{fuchs1982theformat, @@ -47,6 +49,7 @@ author={Bos, Bert and Wium Lie, Håkon and Lilley, Chris and Jacobs Ian}, date={1998}, howpublished={\url{http://www.w3.org/TR/1998/REC-CSS2-19980512/}} + note={Retrieved 2014-05-22} } @misc{ghostscript, @@ -54,6 +57,7 @@ author={Artifex Software}, year={1988}, howpublished={\url{http://www.ghostscript.com/}} + note={Retrieved 2014-05-21} } %%%%%%%%%%%%%%%%%%%%%%%% @@ -97,6 +101,7 @@ type={Blog}, number={February 8}, howpublished={\url{http://fgiesen.wordpress.com/2013/02/08/triangle-rasterization-in-practice/}} + note={Retrieved 2014-05-16} } % A paper on polygon rasterization. Probably should find a nice textbook on @@ -152,7 +157,8 @@ Goldberg:1991:CSK:103162.103163, year={2010}, journal={OpenGL Extension}, publisher={Kronos Group}, - howpublished={\url{http://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt}} + howpublished={\url{http://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt}}, + note={Retrieved 2014-05-20} } @misc{nv_half_float, @@ -161,7 +167,8 @@ Goldberg:1991:CSK:103162.103163, year={2002}, journal={OpenGL Extension}, publisher={NVIDIA Corporation}, - howpublished={\url{http://www.opengl.org/registry/specs/NV/half_float.txt}} + howpublished={\url{http://www.opengl.org/registry/specs/NV/half_float.txt}}, + note={Retrieved 2014-05-20} } @inproceedings{emmart2010high, @@ -612,7 +619,8 @@ doi={10.1109/ARITH.1991.145549},} title = {java.math.{BigInteger}}, booktitle = {Java Platform 6 {SE}}, urldate = {19-05-2014}, - howpublished = {\url{http://docs.oracle.com/javase/6/docs/api/java/math/BigInteger.html}} + howpublished = {\url{http://docs.oracle.com/javase/6/docs/api/java/math/BigInteger.html}}, + note={Retrieved 2014-05-19} } @misc{java_bigdecimal, @@ -620,7 +628,8 @@ doi={10.1109/ARITH.1991.145549},} title = {java.math.{BigDecimal}}, booktitle = {Java Platform 7 {SE}}, howpublished = {\url{http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html}}, - urldate = {19-05-2014} + urldate = {19-05-2014}, + note={Retrieved 2014-05-19} } % A CMOS Floating Point Unit @@ -814,7 +823,8 @@ language={English} journal = "W3C Recommendation", title = "Scalable Vector Graphics (SVG) 1.1 (Second Edition)", author = "Erik Dahlst{\'o}m and Patric Dengler and Anthony Grasso and Chris Lilley and Cameron McCormack and Doug Schepers and Jonathon Watt and Jon Ferraiolo and Fujisawa Jun and Dean Jackson", - howpublished = "\url{http://www.w3.org/TR/SVG/}" + howpublished = "\url{http://www.w3.org/TR/SVG/}", + note = "Retrieved 2014-05-23", } @article{xml2008-1.0, @@ -1040,3 +1050,31 @@ ISSN={0272-1716},} volume={28}, number={3}, } + +@book{de1986shape, + title={Shape mathematics and CAD}, + author={De Casteljau, Paul de Faget}, + year={1986}, + publisher={IET} +} + +@book{foley1996computer, + title={Computer Graphics: Principles and Practice}, + author={Foley, J.D.}, + isbn={9780201848403}, + lccn={lc95013631}, + chapter={Representing Curves and Surfaces} + series={Addison-Wesley systems programming series}, + url={http://books.google.com.au/books?id=-4ngT05gmAQC}, + year={1996}, + publisher={Addison-Wesley} +} + +@book{zerbst2004game, + title={{3D} Game Engine Programming}, + author={Zerbst, Stefan and Düvel, Oliver}, + publisher={Premier Press}, + chapter={Scene Management}, + isbn={1592003516} + year={2004} +} \ No newline at end of file