Institutionen för datavetenskap
Department of Computer and Information Science
Final thesis
PDF Eagle – A PDF viewer in Qt
byLukas Gustavsson
LIU-IDA/LITH-EX-A--12/013--SE
2012-03-30
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/In English
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/Final thesis
PDF Eagle - A PDF viewer in Qt
byLukas Gustavsson
LITH-IDA-EX-2012/
2012-03-30
Supervisor: Ekhiotz Jon Vergara Alonso Examiner: Simin Nadjm-Tehrani
Abstract
To keep up in the rapidly changing market for smart mobile phones, new ways of consuming information is needed. In this master thesis project a Portable Document Format (PDF) viewer with more features than existing PDF viewers for Symbianˆ3 was developed, called PDF Eagle. PDF Eagle was implemented using the Qt framework, allowing it to be easily ported to different platforms. PDF documents have a rich structure and to be fully compatible with the standard and at the same time responsive enough to be run on a mobile platform is a formidable technical challenge. This report describes the issues that had to be resolved all the way to a functioning ”app” that was marketed on the Nokia market in October 2011 with a great success. Among the technical challenges was a way to correctly render coloured objects in PDFs. A gradient is a way to colour an area in a PDF file. Results of tests showed that PDF Eagle is more capable of handling gradients, shadows and encrypted PDF files compared to other mobile PDF viewers. The conclusion of this report is that PDF Eagle is on par with or outmatches other PDF viewers on the targeted platform. This work also shows the feasibility of incrementally downloading the pages of a PDF file which provides a better user experience by faster viewing.
Contents
1 Introduction 1 1.1 Motivation . . . 1 1.1.1 Current system . . . 2 1.1.2 Improvements . . . 2 1.2 Use cases . . . 4 1.2.1 Ordinary viewer . . . 4 1.2.2 Text-only . . . 4 1.3 Problems to solve . . . 5 1.4 Limitation . . . 6 1.5 Problem formulation . . . 6 1.6 Intended audience . . . 7 2 Background 8 2.1 The PDF format . . . 8 2.1.1 Graphics state . . . 9 2.1.2 Lines . . . 9 2.1.3 Colour spaces . . . 9 2.1.4 Images . . . 11 2.1.5 Filters . . . 11CONTENTS
2.1.6 Encryption . . . 12
2.1.7 Forms . . . 12
2.1.8 Text . . . 12
2.2 Targeted devices . . . 15
2.2.1 CPU and memory . . . 15
2.2.2 Screen . . . 15
2.3 Qt framework . . . 16
3 Architecture and design considerations 17 3.1 Basic structure . . . 17
3.1.1 Parser . . . 17
3.1.2 Lexer . . . 18
3.1.3 Reader . . . 18
3.2 Using existing Qt classes . . . 19
3.2.1 Differences between Qt and the PDF format . . . 19
3.3 Incremental updates . . . 20 3.3.1 Server-side rasterization . . . 21 3.4 PDF to text . . . 23 3.5 Search index . . . 23 3.6 Third-party libraries . . . 24 3.6.1 FreeType 2 . . . 24 3.6.2 libjpeg-turbo . . . 24 3.6.3 Little CMS . . . 25 4 Implementation 26 4.1 System description . . . 26 4.1.1 PdfFile . . . 27 4.1.2 PDFContext . . . 27
CONTENTS
4.1.3 TileDrawer . . . 27
4.1.4 Stream . . . 28
4.1.5 CSRImpl . . . 28
4.2 Layers of caching . . . 29
4.2.1 Page images and column data . . . 29
4.2.2 VPictures . . . 29
4.2.3 Colour spaces . . . 30
4.2.4 Fonts and glyphs . . . 30
4.2.5 Images . . . 30 4.3 PDF to text . . . 31 4.4 Search index . . . 31 4.5 Optimizations . . . 31 5 Analyzing results 33 5.1 Test design . . . 33 5.1.1 Viewer . . . 33 5.1.2 PDF to text . . . 34 5.1.3 Incremental updates . . . 34
5.2 Design of test set . . . 34
5.3 Results of tests . . . 36
5.4 Comparisons . . . 37
5.4.1 Compatibility . . . 38
5.4.2 Speed . . . 39
5.4.3 User interface . . . 40
5.5 Meeting the requirements . . . 40
6 Conclusions and future work 41 6.1 Conclusions . . . 41
CONTENTS
Chapter 1
Introduction
The use of mobile devices is widely spread and so is the use of PDF docu-ments. Despite this, many users of mobile devices avoids PDF files due to their sometimes large sizes of several megabytes and due to the problems of navigating in them on a mobile device.
The master thesis examines how to efficiently view and search in a PDF document on a mobile device with the support of server software. The PDF documents will first be parsed by the server software, which can create hints to make the viewing easier for the mobile device. For example the server could scale down large images, index the texts and convert fonts or pre-render PDF pages that are very demanding, off-loading the mobile device from very resource (CPU) demanding operation. The chosen method is demonstrated implementing the PDF viewer. PDF Eagle is the name of the PDF viewer. The implementation was based on an existing PDF parser developed by VISIARC.
This report is based on final project work in partial fullfillment of a 5 year degree program in computer science and engineering at Link¨oping university (30 ECTS points), and was examined at the department of computer and information science
1.1
Motivation
This section describes the motivation of the work performed during the thesis. The status of the current system is described and the possible im-provements are shown.
1.1. MOTIVATION
1.1.1
Current system
Mobile Documents is a mail application developed by VISIARC. One of its key features is the possibility to preview documents and attachments on the phone without downloading them. This is achieved by converting the documents on a server, first to PDF files and then to images and sending them to the client as tiles. A tile is a rectangular image which can be a page or a part of a page, see Figure 1.1.
Figure 1.1: A converted document is sent as image tiles from a server to a client
This system has some drawbacks, the viewing can be a bit slow since the client has to make a connection to the server to get new tiles every time the user moves or zooms in the document. The zoom is also limited, since the image tiles are only generated with limited resolutions. Obviously, since the client only gets images, it can not search in the documents.
The current system is able to show only the text in a PDF file for really quick reading. The feature of showing a PDF as plain text is named PDF to text. Currently Mobile Documents use XPdf [1] for converting PDF files to plain text. Unfortunately, it has many formatting errors.
In 2011, a master thesis investigated the possibility to create a lightweight version of Mobile Documents [2].
1.1.2
Improvements
All information about how the documents are going to be shown are provided in the PDF files. If the client could use PDF files instead of only image tiles there would be several benefits.
CHAPTER 1. INTRODUCTION
the document is not downloaded in different resolutions. • Less conversion job has to be done by the server.
• Most importantly, the user will get a better experience with faster viewing of simple documents and unlimited zooming.
• With the PDF to text utility, it is also possible to search in documents. An alternative was to use an external PDF viewer, but as it is shown in Figure 1.2 it would require extra unwanted steps from the user and it would not allow for a seamless integration with Mobile Documents.
Figure 1.2: Viewing a PDF file from a mail in an external reader There were also open source alternatives that could be included or adapted, but as there were none that could be used freely in proprietary software, they were discarded.
The goal of this thesis was to write a PDF viewer that could read and view (rasterize) PDF files. This allows for implementation of sending only the pages that the user views, so the user does not have to wait for the whole PDF to be downloaded before viewing. The experience should resemble Figure 1.3.
1.2. USE CASES
Figure 1.3: Viewing a PDF from a mail with incremental download in Mobile Documents
1.2
Use cases
Software that can parse and interpret PDF files has several use cases, not only the most common and obvious case where the PDF file is simply viewed in an ordinary viewer. Apart from that case, the text can be extracted and used for different purposes. PDF Eagle covers both these use cases.
1.2.1
Ordinary viewer
The most basic and primary functionality of a PDF viewer is to make the PDF files possible to view. In its most basic form, this use case is like viewing a printout of the document. Without any extensions, it is not possible to interact with the document in any way.
1.2.2
Text-only
Extraction and identification of text content enables a lot of additions and new features to be added to the basic viewer. It also makes it possible for completely new viewing modes, like the text-only mode, where only the text and no graphical layout is shown. This mode is useful on devices with small screens and when your data connection does not allow you to download more information than the most necessary.
When the text is extracted it is possible to use it for building a search index, which makes it possible to search in documents without having to parse through the whole document for each search. This greatly reduces the time it takes to search in documents.
CHAPTER 1. INTRODUCTION
It is also possible to use the same system used in text extraction to add an extra functionality to the ordinary viewer. When extracting text, it is grouped into parts and columns. This can be used for predicting the width of the columns and make the viewer zoom exactly to a column when the user zooms in a document.
1.3
Problems to solve
This work is targeted towards mobile devices, which are resource constrained devices. Taking the resources of a device into account, a good user experi-ence is achieved by quickly rendering and showing pages without consuming much resources. When a page is rendered, a visual representation of it is created from the information in the PDF file. When a page is showed, the visual representation of it is presented to the user.
Even in the newest models of today, an application running beside others can only use a couple of megabytes of RAM. Compared to this a desktop computer with virtual memory has almost an unlimited amount. The speed of the CPU is also limiting the speed of which the rendering can be done. It may not be suitable to always render the whole file as it is. Some files can contain, for example, huge images and take a long time to render. To solve this for large PDF files they can be pre-rendered on a server and sent to the client as images. It had to be decided how the server could determine which parts (if any) of the PDF that has to be pre-rendered.
It was not possible to set a limit on how fast a viewer had to be, but one could always aim to fulfill the requirements in the user interface book TOG on Interface [3], that the program always should be fast enough not to annoy the user. In the case of PDF Eagle, no PDF file should make the application load for a long time without any notification of progress to the user. The client-server communication had to be defined in order to be able to send incremental updates of the PDF file. The client needs to be able to put together parts of the file obtained at different times.
The PDF to text functionality is available in some programs today, but with a lot of character and layout problems. These problems had to be found and solved in the implementation.
When making the PDF files searchable it had to be decided how the search index should be built, how and where it was going to be stored and how the result would be presented on the client.
1.4. LIMITATION
1.4
Limitation
Due to the time restriction of a master thesis project, the work was focused on doing a stand-alone PDF viewer, a PDF to text utility, indexing the PDF files and preparing for implementation of search functionality and making an analysis of how to implement server acceleration of the PDF viewer. Implementing a PDF viewer that is accelerated by a server and which is able to search in PDF files was left for future work.
1.5
Problem formulation
The goal of this thesis is to have a working stand-alone PDF viewer that can rasterize and show pages. There will also be a seperate program that can convert PDF files to text and index them for searching. Also, an analyze of how the viewing experience can be improved with the help of a server will be done.
Below is a concrete list of the minimum requirements. For the master thesis to be considered complete by VISIARC these need to be completed.
1. Implementation of a working stand-alone PDF viewer that can ras-terize pages into tiles. This can be used either by an OpenGL based viewer or by a Server.
2. Implementation of the PDF to text functionality.
3. Development of a search index making PDF files searchable. 4. Analysis of the PDF rasterizing for example:
• A particulary demanding PDF page can be rasterized server-side and the client side only uses the tiles to show that particular page.
• Incremental sending of PDF pages to the client.
The requirement 1 is considered to be complete when it could be demon-strated on a Symbian device on PDF files containing ordinary content. These PDF files are a set of test files provided by VISIARC. The requirements 2 and 3 are considered complete when the test PDF files can be shown as or-dinary text and indexed for searching. The fourth requirement is considered complete when an implementation is possible to do based on the results of the analysis.
CHAPTER 1. INTRODUCTION
1. Implementation of the incremental sending of PDF pages, resulting in a complete PDF file once finished.
2. Visual hinting of search results within a PDF. 3. Support for showing PDF annotations.
4. PDF files can contain scaling information. How to use that in order to measure physical distances from the PDF document.
1.6
Intended audience
To be able to fully read and understand this master thesis, general knowl-edge of computers in level with a student of master of science in computer engineering is expected.
Chapter 2
Background
This chapter presents the basics of the PDF format. Specifically, the con-struction and the parts of a PDF file are described. Moreover, the most common and relevant objects (from the point of view of this thesis) are also presented. It will as well present what kind of devices the work of this thesis is aimed at and describe the limitations that those devices impose on a PDF viewer. The framework used, Qt, to do the work of this thesis will also be described in short.
2.1
The PDF format
PDF (Portable Document Format) is a file format developed by Adobe Sys-tems in 1993. It is a format that describes how a document shall be viewed, regardless of which kind of hardware device it is viewed on, and regardless of which software used to view it. Since 2008, the PDF format is an open standard published by the International Organization for Standardization as ISO 32000-1:2008 [4]. Adobe still holds various patents related to the PDF format, but it is royalty free to develop and distribute software that deals with PDF files.
A PDF file consists of three main parts: objects, document structure and file structure.
• Objects: In a PDF file there are different kinds of data objects. These range from simple boolean objects that consist of either the value true or the value false to complex content streams that contain sequences of operators and operands describing how pages or other graphical elements shall be rendered.
CHAPTER 2. BACKGROUND
• Document structure: The document structure describes how objects are used in making different parts of a PDF file, most importantly the pages.
• File structure: This part of a PDF document specifies how objects are stored in a PDF file and how they can be accessed. This is the first part of the file that gets read by a viewer.
A content stream contains a dictionary with resources and a sequence of op-erators and operands. Together they describe how different types of graph-ical elements shall be rendered. The content stream itself can be encoded by one or more encodings which have to be decoded before any data can be read from the content stream.
2.1.1
Graphics state
When reading a PDF file, a PDF viewer always holds a state, called the graphics state. This state contains information about how the graphical objects are to be drawn. Among other things it includes data about the current scale which objects are to be drawn in, the colours of stroking and filling, which colour space to use and the thickness of lines. It also holds information about how text is to be drawn, such as which font to use, the font size and the spacing between the characters.
2.1.2
Lines
Lines and areas are made up of path segments which may or may not be connected. The segments can be either straight or curved and a path is defined by a sequence of operators constructing these segments. When a path has been defined of various segments, it is painted in some way by a path painting operator. It can be either filled, stroked, both or neither. Figure 2.1 shows a path consisting of one straight line segment that is stroked. When stroking a path, its outline is drawn. Figure 2.2 shows a path made out of four curved line segments that has been filled, but not stroked. Each line segment is a quarter of the circle and when they are combined to a path, it leads to the final circle figure.
2.1.3
Colour spaces
Colour spaces are used for defining which colour graphical objects should be drawn in. There are three different types of colour spaces: device colour
2.1. THE PDF FORMAT
Figure 2.1: A stroked path consisting of one line segment.
Figure 2.2: A filled but not stroked path consisting of four curved line segments.
spaces, CIE-based (Commission Internationale de l’ ´Eclairage, International Commission on Illumination) colour spaces and special colour spaces. In a device colour space, which is the simplest type of a colour space, the amount of each colour used is directly specified. For example the DeviceRGB colour space specifies how much red, green and blue, the colours used in displays, to use when drawing. Because DeviceRGB has three components, three numbers are required to specify a color in this colour space.
The CIE-based colour spaces are derived from a standard of colour speci-fication from International Commission on Illumination. This colour space
CHAPTER 2. BACKGROUND
specifies colours so that the colours always look the same, regardless of which medium they are displayed on. When using these colour spaces, additional information is attached to define the colour space.
Special colour spaces are defined by adding extra information to an under-laying colour space (e.g., DeviceRGB) about how to use this colour space to achieve for example complex patterns in a simple way. For example, the Pattern colour space can contain a graphical object and information on how this figure shall be repeated. The object of which it is made up of uses the underlying colour space when drawn. See Figure 2.3 for a chess tiled example.
Figure 2.3: Usage of tiling pattern colour space illustrated. The tile to the left can be used to paint the chess tiled square to the right.
2.1.4
Images
An image in a PDF file is basically an array of sample values, each repre-senting a colour component. Moreover it also specifies the width and height of the image, the colour space to use (from this the number of colour compo-nents per sample is derived) and how many bits a colour component consists of. Usually, the data array is encoded to save space, for example using the compression used in JPEG image.
2.1.5
Filters
Most data streams in a PDF file, like content streams and image data, can be compressed. By applying one or many decompression filters, the nonencoded data is restored. For example image data is often required to be decoded by the CCITTFaxDecode filter (this compression is implemented in the TIFF format) or the DCTDecode filter (mostly known to be used in JPEG images). To compress content streams with operands and operators the zlib/deflate method (known from the ZIP format) is more effective in reducing size and is decompressed by the FlateDecode filter. Apart from
2.1. THE PDF FORMAT
the three filters named here, there are seven more different filters that can appear in a PDF file, one of them being an encryption filter used only to protect data.
Due to the many different filters supported, a PDF file reader needs to be able to decompress a wide range of different kinds of compressed data before it can actually interpret it.
2.1.6
Encryption
To protect a PDF file from unauthorized access the format supports encryp-tion of strings and data streams. It is also possible to protect single parts of data in an unprotected PDF document by using an encryption filter on the data streams containing the data that needs to be protected.
The encryption of a PDF document is controlled by software called security handler. This handler is responsible for the encryption process and can implement any encryption algorithm. However, a standard security handler is specified by the PDF format supporting two encryption algorithms, Rivest Cipher 4 (RC4), developed by RSA Security, and Advanced Encryption Standard (AES).
2.1.7
Forms
A form object is an object that is composed of other objects. It can be graphical objects as lines or images as well as text objects. A form object can be rendered multiple times and the result shall always be the same, the only differences are those defined by the graphics state, such as scale and colour.
This can be beneficial for the size of the PDF document if a complex graphic element only has to be defined once and then reused, instead of being defined each and every time it shall be drawn. A common example is a company logotype that appears on top of every page in a PDF document. PDF viewers can also make profit from forms, since forms make it easier to cache parts of a document. Figure 2.4 shows an example of how an image rendered using a few forms drawn a lot of times can look like.
2.1.8
Text
The basics of showing text in a PDF file is that each character shall be represented by a glyph and drawn on the right place in the right size. A
CHAPTER 2. BACKGROUND
Figure 2.4: An image rendered using three different forms [5]. glyph is the graphical representation of a character. The characters to draw are obtained from text objects which contain arrays of characters. The size and place is stored in the current graphics state along with which font to
2.1. THE PDF FORMAT
use. The font can be either embedded in the PDF file, or it can be excluded. Embedded fonts
If the creator of a PDF file wants to be really sure that the document is going to look exactly the same regardless of the device and the PDF viewer used, the fonts for all text written in the PDF file has to be embedded. When embedded, all information about how each glyph is drawn is read from the font data in the PDF file and the document gets the exact same look and layout everywhere.
Non embedded fonts
When the font to use is not embedded, the PDF file includes the name and information of the font to use. If the font is installed on the device viewing the PDF file all glyphs are read from that font and the document gets the layout intended by its creator. If the device does not have the font installed the PDF viewer shall find a font that looks as close to that font as possible. Examples of the information of font properties include the type of font (Serif or Sans-serif), bold or italic, the width of the glyphs and if it resembles hand writing. Figure 2.5 shows an example of how a text using a font not embedded can be rendered differently on different PDF viewers.
Figure 2.5: An example of a text using a font that is not embedded in the PDF file. From the top, the PDF viewers used are: PDF Eagle, Adobe Reader and Foxit Reader.
CHAPTER 2. BACKGROUND
Mapping of character to glyph
Finding which glyph to map to each character is made in different ways depending on the type of the font There are five different main types of fonts and the way to map character to glyphs differs among them. This mapping is called the font’s encoding and for simpler fonts there are several different pre-defined encodings that need to be considered.
2.2
Targeted devices
This work was targeted towards Symbianˆ3 powered devices from Nokia, mainly E7 and N8. They are resource constrainted devices in terms of CPU and RAM. The size of the screens also make it more difficult to present PDF files to the user.
2.2.1
CPU and memory
When making an application for Symbianˆ3, the maximum amount of mem-ory it is allowed to consume had to be specified. This differs from desktop computers, where for example a PDF viewer can consume magnitudes of more memory if a resource intensive document is opened. The CPU speed (680 MHz in the N8/E7) is also significantly lower than the speed of the CPU in a modern desktop computer, which simply makes rendering of PDF files slower.
The I/O on handheld units also affects the performance of reading and saving from and to caches in the application. Depending on where the application is installed (RAM, internal memory or memory card), reading and writing rates are different.
2.2.2
Screen
Even if the resources in a mobile device are limited and makes viewing of a PDF file slower, a limitation that has an even bigger impact on the viewing experience is the screen. Since the screen is only 3,5” for the N8 and 4” for the E7, it is simply not possible to view a whole page of a PDF file and still be able to read the text (assuming the text is in the 12-14 point range).
2.3. QT FRAMEWORK
2.3
Qt framework
Qt is an application framework used in this project. It is cross-platform, which means that even if the target platform is Symbianˆ3, the code can be compiled and natively run on several different platforms, such as Mac OS X and Windows.
Qt was originally developed by the Norwegian company Trolltech, which was acquired by Nokia in 2008 and the development has since then continued under their flag. The release version of Qt that is used in this work is 4.7.3. Since 2009, Qt is released with the GNU Lesser General Public License (LGPL) which allows it to be freely used in commercial applications [6].
Chapter 3
Architecture and design
considerations
This chapter describes the decisions that were made when the architecture and design of this work were laid out. It aims to give a good understanding of the reasoning behind the decisions made during the project, specifying the possible alternatives and the reasons to choose the most suitable one.
3.1
Basic structure
The structure of the PDF viewer consists of three main parts: a parser, a lexer and interchangeable readers. This section describes them. Figure 3.1 shows a simplified overview of the system architecture. Bits are read from the file and sent to the parser which converts them to characters and sends them on to the lexer. The lexer converts the characters from the parser into instructions which the reader can interpret. The reader then converts the instructions into graphical objects shown to the user.
3.1.1
Parser
A parser is the component that reads bytes directly from the streams in the PDF file. The type of selected parser is a rescursive descent parser, which is a top-down parser [7]. A top-down parser tries to match the input symbols to the highest level of the parse tree and goes down different routes in the tree depending on whether the input matches or not. The recursive descent
3.1. BASIC STRUCTURE
Figure 3.1: An overview of the basic architecture.
parser uses a recursive procedure for each of the grammar rules of the parse tree.
This type of parser was decided because it is a parser that is simple to implement without having to use for example parser generators that adds complexity to the project. It feeds characters from the PDF file or from encoded streams in the PDF file to the lexer. The design of the parser was chosen before this master thesis and the decision was mostly about whether it could be used or not. Since it did work, replacing it was not considered.
3.1.2
Lexer
A lexer is the component that converts the characters from the parser to tokens, such as booleans, integers, strings, operators or other data types that are defined in the PDF format. The tokens are combined as instructions that shall be sent to the reader. As an instruction consists of an operator and operands, if any, the lexer can interpret all the data types in the PDF format. Therefore it was unnecessary to add any more complexity to the lexer. When all information of an instruction is read, it is sent to the reader.
3.1.3
Reader
The reader is the part that interprets instructions in the shape of an operator and zero or more operands and takes the appropriate action depending on the instruction that was received. For example, if the reader is the text extractor, all instructions except those affecting the text are discarded. If the reader instead is the ordinary viewer, almost all instructions influence the rendering and have to be taken care of.
Since the stream of data that defines the content in a PDF file consists of a set of instructions that needs to be executed in order, the reader that can interpret the instructions is defined by the PDF format itself. Having the reader separated from the rest of the system makes it easily interchangeable. The interchangeability could be used by PDF Eagle by having one reader
CHAPTER 3. ARCHITECTURE AND DESIGN CONSIDERATIONS
for displaying the PDF in the usual way, one reader for converting the PDF to plain text and one reader for building a search index.
When the reader has finished a command, the next command is immediately pushed from the lexer. Instead of this push design, a pull variant could be used, where the reader has to ask the lexer to send the next command. An advantage of using pull instead of push is that it gives more control over the flow of the program and makes it easier to cancel as it is easy to just stop pulling more commands. This state could be saved and when the user’s focus is shifting back to this page, rendering could be continued. However, as this is possible to do even if the reader gets the commands pushed, the simpler push design was chosen.
3.2
Using existing Qt classes
When implementing a PDF renderer in Qt, an important class to use is the QPainter class. QPainter provides functions to perform many different drawing operators. It provides both simple functions like drawing a line and more complex ones like filling an area with a gradient. These functions turned out to be very useful when deciding how to make the graphics in the PDF viewer. Many of the drawing operations described in the PDF format either maps directly to a function in the QPainter class, or can take great advantage of them.
An example that resembles the description in the PDF format well is the pen and brush. In both Qt and the PDF format it is possible to set properties such as colour or width for stroking operations to both a pen and a brush. The concept of having a stack with graphics states stored is another example of similarities.
3.2.1
Differences between Qt and the PDF format
Unfortunately, the match of the drawing operations in the PDF format and the functions in Qt are not perfect. There are small differences, such as not being able to set exactly how a clipping path (a path that embraces the paintable area) is defined or not being able to set all properties on shadings with cylindrical shapes. These kinds of differences seldom produces any noticeable variations in the resulting pages and the Qt functions were therefore used as satisfying approximations.
An area where the embedded Qt functions were not good enough was the text and font usage. The PDF format is very strict about which fonts to use and sometimes even includes the font file to use, as described in section
3.3. INCREMENTAL UPDATES
2.1.8. This file is not possible to simply load in Qt. This was the main reason for choosing to use FreeType [8], an open source third-party library for font rendering, for all text rendering purposes.
3.3
Incremental updates
The objective of being able to send a PDF file from a server to a client in incremental steps is that the client should be able to view a page as quick as possible, without having to wait for the whole PDF file to be downloaded. Downloading the whole file could possibly take a long time if the network connection is slow. Hence, for the fastest and most effective viewing, only the data that the client actually is going to read should be sent.
The client has to be able to store and read the fragmented data the server is going to send. It must also be able to ask the server for more data when it does not have the parts needed to view a page. It must tell the server which pages to send and which pages it has already recieved to avoid sending the same data twice. When the client has received some data, it should also be able to reconstruct the whole document exactly as it was stored on the server, without having to download the already downloaded pages again. The downloaded parts must therefore be possible to place in their correct location in the final file.
In summary, this reasoning lead to the following requirements for the server and the client:
1. The server must not send more data than the client needs to view the page.
2. The client must know when it can show a page and when it needs more data.
3. The client must be able to read an incomplete file.
4. The server must be able to send all missing parts of a file to the client when the client wants to reconstruct the whole file.
The cross-platform property of Qt was a great advantage at the time of developing the code for the server. The same code that read and views PDF files on the client could be run on the server, allowing the server to log which parts of a PDF file is needed for each page. This approach made sure that the client gets all the data it needs, since the same code and therefore logic selects the parts needed for the incremental update. The client keeps track
CHAPTER 3. ARCHITECTURE AND DESIGN CONSIDERATIONS
of the already downloaded pages by storing which pages it has downloaded in a separate file.
The downloaded data is inserted in a new file of the same size as the orig-inal file and is initially filled with dummy data. Using this file, the client can read the pages downloaded without having any problems or additional modifications, since all data it is going to read is correct and with correct offsets. The new file can be stored in a smaller way without dummy data, but if it is, the viewer must be modified to read the fragmented PDF file in a different way, since all offsets in the PDF file would be wrong. Being able to use the existing viewer without any major modifications reduces the risk of new bugs and saves developing work at the cost of storing some dummy data on the client.
Using the proposed design, the client can tell the server which pages are already downloaded. Therefore, no data from the PDF file that the client already got has to be downloaded again, since the server can make a simple analysis to find out what the client is missing from the complete file. Figure 3.2 shows the communication between the client and the server in a scenario where the user first reads page 2 and then page 3 and 4. When this is done, the user downloads the rest of the file without having to redownload anything.
3.3.1
Server-side rasterization
To achieve an even faster viewing, the incremental downloading can be com-bined with server-side rasterization of really heavy PDF pages, similar to the tile concept currently used by Mobile Documents. If such a feature is used there has to be a limit on when a page is to be sent in the usual way and when it is to be pre-rendered on the server and sent as tiles. There are different ways to set a limit, each with pros and cons, as the following list shows.
• A simple size limit: Using a limit of the combined size of all objects on a page is simple. It is easy to measure the total size and the client does not risk to get stuck downloading huge amounts of data. However, since pages in a PDF document can share objects, the objects in a huge page can potentially be used on a lot of other pages in the document and may already be downloaded.
• Command number limit: A limit on the number of commands on a page is also easy to implement. The problem with this approach is that a command can be everything from a simple line to a block of
3.3. INCREMENTAL UPDATES
1. Send page 2
S
E
R
V
E
R
C
L
I
E
N
T
2. The data of page 2 3. Send page 3 and 4 4. The data of page 3 and 4 5. Send rest of PDF 6. All unsent PDF dataFigure 3.2: Communication between a client and a server when the client is viewing a PDF document using incremental download.
text or an image. Therefore, a page with a huge image may not be pre-rendered while a page with just a lot of single lines will.
• Weighted commands: An alternative to simply count the commands is to give each command a certain value depending on which type it is, and possibly a higher value if it has a lot of operands. This type of limit takes more work to develop and configure, but is more configureable. • Rendering time: By using a limit on how long time it takes for the
server to render a page it does not matter if a page has one huge object or several small. The drawback with this approach is that the server is not the same device as the client. An operation which is fast on the server can take longer on the client due to different hardware. Measuring rendering time on the server is not suitable to do in real time (seconds) beacuse the server may be more or less loaded. It is better to use CPU clock cycles instead, although it is not perfect since
CHAPTER 3. ARCHITECTURE AND DESIGN CONSIDERATIONS
it means that any I/O waiting time is not accounted for.
By using one of these alternatives or combining two or more, identifying heavy PDF pages can be done, although not in a perfect manner.
3.4
PDF to text
The basis of the PDF to text feature is to convert the text from a PDF document to plain text.
However, the text of a PDF file is defined as glyphs in different positions in a font file. It does not need to tell anything about which characters the glyphs actually represent. This makes the conversion difficult. When the PDF file provides extra information about the characters the conversion is easy to do. Most new PDF files support this feature. Otherwise, a best effort will be made to find the information from the font file.
When a PDF page has been parsed, the text will be converted into para-graphs depending on its position on the page.
3.5
Search index
The purpose of a search index is to have fast access to the information of the text in a document. Without any index, a search in a PDF file would have to parse through all content streams to look for the wanted word or phrase. With an index, a full-text search (FTS) can be performed in fractions of a second even in a PDF file with large text content.
There were several FTS libraries that could be used for indexing and search-ing, such as Xapian [9] or Lucene [10]. Both are fully featured libraries well suited for the task. An alternative was to use an extension to the SQLite database, FTS4. This extension allows the quick full-text search in a database.
Since the amount of text in a PDF file often counts in hundreds or thousands of words rather than in millions, given the size of the problem, the simplest solution was enough. The fact that PDF Eagle also will split the text into columns with positional information and that PDF Eagle are going to get functionality of converting a PDF document to text supported the decision of the easier route of SQLite.
A drawback of SQLite FT4 and full-text search in general is that wildcard (a character that may be substituted for any other character string) searches
3.6. THIRD-PARTY LIBRARIES
are not fully supported. Postfix searches, such as ho*, is a fast operation and will match both house and host. Suffix searching can be achieved by storing one copy of the search index backwards and then doing a postfix search. Unfortunately, doing a search such as *hou* is much slower. Still, it is faster than parsing all content streams in the PDF file.
3.6
Third-party libraries
As a key part of software development is not to reinvent the wheel when it is not needed, third-party libraries were used for performing certain tasks. This libraries provided important functionality to the developed PDF viewer. As PDF Eagle was not intended to be open source, the libraries must not have any open source license requirement.
3.6.1
FreeType 2
FreeType 2 is a font engine which is used to render fonts. When some text is to be rendered, the according font file is loaded into FreeType 2. Afterwards, for all characters in that font, it is possible to get a glyph outline from FreeType 2 which is used to draw the glyph.
By using this library, PDF Eagle did not need to have any font engine of its own and no parsing of font files had to be written.
3.6.2
libjpeg-turbo
To decode image streams decoded with the DCTDecode filter libjpeg-turbo [11] was used. libjpeg-turbo is based on the library libjpeg [12] with numer-ous enhancements to achieve a faster decoding. All of these enhancements could not be taken advantage of by PDF Eagle since the processor used on the target platform does not support all instructions used. However, libjpeg-turbo decodes at least at the same speed as the library it was branched from, libjpeg.
The advantages of using the libjpeg-turbo library instead of writing a jpeg decoder just for PDF Eagle are quite obvious. This library provides a fast and publicly accepted correct decoding. Without a lot of work, it would be hard to create a decoder that is better.
CHAPTER 3. ARCHITECTURE AND DESIGN CONSIDERATIONS
3.6.3
Little CMS
To handle some of the more advanced colour spaces which can occur in a PDF file, the colour management engine Little CMS was used. It performs transformations between different colour profiles and by using this library PDF Eagle did not have to be able to parse ICC profiles by itself and a lot of extra code developing concerning colour profiles was avoided.
Chapter 4
Implementation
In this chapter, a brief description of how the software was implemented is given. It presents the system, its data caching method and a number of optimizations to improve the rendering speed.
4.1
System description
The entire PDF Eagle project consists of 87 Qt classes, all except the parser and the lexer created during this work. Both of the existing classes has been modified in the development. This section will provide a short description of the relationship between the most important of the classes and for some of them a more detailed description will be presented.
Figure 4.1 shows the program flow between the main classes in the applica-tion when a user views a non cached page. A PDF file is loaded as a PdfFile class through the PDFContext class and a request for a tile of the viewed part of the actual page is sent to the TileDrawer class. In the TileDrawer, a tile of the appropriate size is created and a parser starts to parse the ac-tual content stream in the PDF file, represented by the Stream class. The instructions are sent to an instance of the CSRImpl class where they are interpreted and drawn to the tile. When the whole stream is parsed the tile is returned to the PDFContext class for delivery to the user interface.
CHAPTER 4. IMPLEMENTATION
Figure 4.1: The flow between some of the main program classes.
4.1.1
PdfFile
PdfFile is the class that handles the actual PDF file on disc. From here a parser to a stream in the file can be created and object streams can be acquired from references. Some of the temporary caches are stored and managed in this class.
4.1.2
PDFContext
PDFContext is the class used for communication with the user interface when PDF Eagle is used as an ordinary viewer. There is only one instance of this class and it is never closed. The PDFContext class handles the opening and closing of the PDF files. It also manages the resources allocated. This class contains an instance of the TileDrawer class and when the user interface wants a new part of a page generated or wants to cancel generation of a previously requested tile, the requests are made to PDFContext.
4.1.3
TileDrawer
This class does exactly what it sounds like it is doing, it provides tiles. It takes requests consisting of what part of a page to draw on a tile, and in which resolution. It does some calculations to match the coordinate system of the request with the coordinate system in the PDF file. This is needed because some of the pages in a PDF file can have their internal coordinate system rotated or scaled. This transformation is something that is not supposed to be exposed to a person viewing the PDF document. If the tile
4.1. SYSTEM DESCRIPTION
requested is stored in the file cache with the correct resolution, or stored in a local cache, it is loaded from there and can be returned quickly. Otherwise, a renderer is created and the page is rendered.
The tiles are rendered asynchronously and the rendering can be cancelled at any time, for example if the user scrolls away from a page or zooms out.
4.1.4
Stream
The purpose of the Stream class is to act as a converter from encoded data streams to decoded data streams. The Stream class is initiated with the information about which stream in the PDF file it should decode. When the decoded data is requested for the first time, it checks how the data is encoded, applies the correct decodings and returns a handle to the decoded data.
4.1.5
CSRImpl
The name of this class, CSRImpl, stands for ”Content stream reader im-plementation”. Within this class the different rendering commands of the content streams in a PDF file are interpreted and turned into lines, colours, text and everything else that can be represented in a PDF file. Over 50 different commands are supported. It is instantiated with references to a PdfFile object and a VPicture object along with information about which page it is rendering.
VPicture is a class which is able to record drawing operations and replay them. When an object on a page of a PDF file should be rendered, it is sent to the VPicture class. From there, it is rendered to an image using the current size and resolution. It is also serialized and saved to a byte array along with a byte telling which command it is. If another part of the same page should be rendered later on, the VPicture can be replayed to an image of a different size and resolution without having to parse anything from the PDF file.
When everything is instantiated, the page is rendered by feeding operands and operators from the parser. For each operation, or sometimes for a series of operations, information is sent from CSRImpl to the VPicture of what to draw.
When the rendering is complete, the CSRImpl class puts together the in-formation of the text placement in the rendered part and calculates which columns of text the page contained and which their boundaries were. This information is also sent to the VPicture.
CHAPTER 4. IMPLEMENTATION
4.2
Layers of caching
PDF Eagle uses several layers of caching, ranging from caching entire images of generated pages to caching paths of rendered letters when rendering. A list follows listing the main things being cached in PDF Eagle to reduce the time it takes to show a page to the user.
• Entire page images and column data • VPictures of rendered pages
• Colour spaces • Fonts and glyphs • Images
The application is allowed to use a maximum of 128 MB of RAM. To prevent the application from running out of memory, all internal caches together may only use one fourth of that memory, since the rest is needed by the application for rendering PDF pages containing a lot of large objects. The caches which are stored on a file are allowed to use more space, up to 40 MB each. This number is chosen as a trade-off, a larger cache would give more cache hits and a faster viewing. However, if PDF Eagle is installed on the internal memory of a Symbianˆ3 device (which is a couple of hundred MB), the caches are not supposed to use all of the storage space.
4.2.1
Page images and column data
When a whole page or a part of a page has been rendered a PNG image is produced, together with information of how many columns of text the page contains and where those are located. If the image consists of the whole page, it is cached in an SQLite database. The next time the user scrolls to this page, it is immediately fetched from the database and shown without having to render anything again. If only a part of the page has been rendered, it is not cached. The cache has a limited size and when it is hit, the oldest half of the cache is cleared.
4.2.2
VPictures
A VPicture is generated the first time a page or a part of a page is rendered. Since it consists of a series of commands stored in an array, it is very simple to cache in a SQLite database. When another part of this page has to be
4.2. LAYERS OF CACHING
rendered and there is no pre-rendered image cached, the commands in the VPicture are replayed producing the requested part of the page with the requested zoom level. Replaying a VPicture is a lot faster than reading a PDF file directly, since no decoding of data has to be done and no font files or special colour spaces have to be parsed. Analogously to the page image cache, the cache of VPictures has a limited size and the oldest parts are removed once it is hit.
4.2.3
Colour spaces
Some of the more advanced colour spaces require parsing of a stream con-taining information of the colour space before it can be used. If the rendering switches between colour spaces, the stream must be parsed over and over again if the result is not cached. In order to avoid this costly operation, the first time a colour space is parsed it is placed in a temporary cache that is cleared every time the application is closed or a new PDF file is opened. This allows the rendering to switch between colour spaces without parsing each colour space more than once.
4.2.4
Fonts and glyphs
Like certain colour spaces, selecting a font requires parsing of the font file, something that potentially can occur many times in a document with several types of text. Therefore, the parsed font files are kept open for quick access in case they are needed again. All opened font files are closed when the application is closed or when another PDF file is opened.
Apart from having quick access to the entire font files, each time a glyph outline is read from the font file, that outline is saved in a temporary cache for even quicker access next time the same character is rendered.
4.2.5
Images
When rendering an image in a PDF file, it has to be decoded if any filter has been applied to it. If an image is drawn more than once, time can be saved by only decoding it the first time. Images does however use a lot more memory than fonts or colour spaces, and simply saving all decoded images in a temporary cache would quickly make it use too much memory. To prevent that from happening, the cache has a fixed size and is cleared when it grows too big. Further, an image is not cached on its first occurrence, but when it is encountered the second time. Most images only occur once and does not need to be cached, but if an image occurs twice, the probability for it
CHAPTER 4. IMPLEMENTATION
to occur even more times is higher and this solution tries to take advantage of that.
4.3
PDF to text
The implementation of PDF to text was analogous to the design. The parsing of the PDF file is done in the same way as when drawing the page, but no drawing commands except for positioning are interpreted. For all text commands, a best effort is done to find out which characters they are composed of by checking the Unicode tag or their position in an eventual character encoding set. If none of these ways are possible, the text is ignored since the information wanted is not included in the document.
4.4
Search index
As mentioned in the design chapter, the decision for the search index was to use SQLite with the FTS4 extension to index and search. The indexing process uses the PDF to text feature and puts the text from each column in separate rows in a SQLite database, along with placement information about the column. This allows for fast retrieval about on which page or pages and which column or columns the requested word appears in. The search is not completed when the column is found. To find the exact location of the requested word in the page, the content stream of the page has to be parsed looking for the word. Since the amount of text in a single page and a single column can not be very large it is a quite fast operation.
4.5
Optimizations
Using the profiling tool Callgrind [13], a tool which records all function calls and calculates how long time the application spends in each function, a graph over the application was created. By analyzing this for a couple of PDF files with different feature sets, it was possible to find several places in the application where time was unnecessarily wasted.
For example, each call to CSRImpl (4.1.5) copied the objects used as operands. By sending pointers to these objects instead, no time at all had to be spent copying the objects. Callgrind also showed the need of internal font, colour space and image caches. It also pointed at some inefficient calculations of gradients and shades which could be identified and fixed.
4.5. OPTIMIZATIONS
The profiling were done on a desktop computer and that environment is not exactly the same as on a Symbianˆ3 device, the exact numbers in the resulting profiling graphs may be different compared to if the profiling could be done directly on the device. The effort required to get Callgrind to work on Symbianˆ3 was to large to be motivated by more exact numbers. A potential bottleneck which can not be discovered by Callgrind is I/O. Time spent waiting for data to be read or written are not recorded.
Chapter 5
Analyzing results
This section describes the tests performed on the final application and lists the results. It also analyses whether the list of the requirements for the master thesis (Section 1.5) are fulfilled or not.
5.1
Test design
The different parts of the software were tested in slightly different ways. Below is a description of how three of the main parts were tested.
5.1.1
Viewer
The correctness of rendering in the ordinary PDF viewer was tested by comparing the output to the output of the desktop version of Adobe Reader of the same PDF file. Adobe Reader was chosen as it is said to be fully compliant with the PDF specification [14]. If the outputs were identical, the test was passed. If the outputs were not identical but the differences were minor and did not hinder the viewing experience of the PDF file, the test was also passed. A minor difference in this case could for example be a gradient being slightly different in colour tone or the thickness of a contour line of a figure differing slightly.
5.2. DESIGN OF TEST SET
5.1.2
PDF to text
To test PDF to text two things needed to be tested. First, the text should be correct, including special characters. Second, the text should be correctly split into columns. For this test to be passed, the columns should be the same and in the same order as they visually appear in a PDF viewer. Since the information about the characters of a text is not always stored in a PDF file, all PDF files do not produce a correct output in PDF to text. If the output was similar or better than the PDF to text utility in XPdf the test was passed. XPdf was chosen as a reference because it is the tool Mobile Documents is currently using to convert PDF files to plain text.
5.1.3
Incremental updates
The testing of the incremental updates feature consisted of splitting the PDF file and storing the parts needed to view a page in a new file. If the new file could be opened by PDF Eagle and viewed without problems, the test was passed.
5.2
Design of test set
The testing of different features in the PDF Eagle viewer was performed by gathering a large set of PDF files, each containing one or several distinct properties. When testing, it is preferred to have as small test PDF files as possible, containing only content of the type that should be tested. This makes it simpler to see if the tested feature does not work as intended. In a PDF file containing a lot of different texts and graphical elements, it can be hard to tell why something is not correctly rendered.
Unfortunately, the set of PDF files provided by VISIARC at the start of this thesis was not composed in this manner. They were rather complex and even if all of them did not make use of advanced PDF features, they contained a lot of different kinds of elements making them unsuitable for tests of particular features. Since a feature can be used in many ways, combined with other features (for example in forms, shadings, translations or patterns) it can be hard to confirm that it always works, under any circumstanses. Therefore, a PDF test set was designed in order to test the different properties.
Initially, some very simple PDF files were created covering the most basic features of PDF. The PDF file shown in Figure 5.1 was the first to be used. It covers only some of the most basic features, but it still contains 834
CHAPTER 5. ANALYZING RESULTS
rendering commands.
Figure 5.1: A simple PDF file for testing basic line drawing and colouring features.
Creating a PDF file for each feature that should be tested was not possible when the features got more advanced and more rarely used in PDF writers. PDF files with said features was instead actively searched for and a test suite was built that way. This test suite was combined with an old collection of PDF files from Adobe containing a large subset of all of features in the PDF specification. Using the test suites combined (a total of over 200 PDF files) test PDF files including, but not limited to, the following features were available:
• Lines and areas • Clipping paths • Font interpretation • Text visualization • Colour spaces • Images • Inline images • Forms
5.3. RESULTS OF TESTS • Graphics state • Patterns • Filters • Encryption
5.3
Results of tests
Each of the categories in the bulleted list in the previous section represent a set of features and the results of the tests concerning the features are explained here. For the sake of brevity, the general results of each feature are described below avoiding the small details of each test. Some issues are also commented. When a feature was not tested as was the case with some font encodings and images, it was because of lack of PDF files using that feature.
• Lines and areas: all kinds of lines (continous, dashed, dotted, etc.) were tested and worked. There is one issue with lines which should al-ways be one pixel wide, in some zoom levels they appear to be thicker. Filling of areas worked in all tested cases.
• Clipping paths: there are some cases when the clipping paths did not work as intended, but for a large majority of the tested cases the clipping paths worked as intended. The failing cases occured when the drawing area was transformed after the clipping path was applied. It seemed that there was a bug in the QPainter function used, but the bug was rare enough to continue using it.
• Font interpretation: the interpretation of fonts was correct in the ma-jority of the tested cases, over 100 PDF files including different fonts. In 3 cases single special characters were not interpreted correctly. It did also fail on 2 of 10 cases with oriental alphabets. Text with the PDFDocEncoding or the MacExpertEncoding encodings have not been tested due to lack of test PDF files.
• Text visualization: all rendering modes (no outlines, only outlines, etc.) for text except the ones where the glyphs are filled with the help of clipping paths have been tested and worked. The rendering modes involving clipping paths were not tested due to lack of PDF files using those features.
• Colour spaces: all colour spaces are supported and were tested. The pattern colour space can sometimes produce the wrong result. The
CHAPTER 5. ANALYZING RESULTS
Lab colour space does not produce the same colour tone as Adobe Reader, however it is still similar. For all other cases, the tests were passed.
• Images: an image can be constructed in any colour space and coded with all kinds of filters. All colour spaces and all supported filters tested worked. Some of the more advanced colour spaces were not tested as the underlying colour space for an image as no PDF files using that feature were found. An image can also have different number of bits per colour component. PDF Eagle was tested and works for 1, 2, 4 and 8 bits per component. The last possible value, 16, is not supported and was not tested due to lack of PDF files using the feature.
All tests involving inline images were passed. As for regular images, inline images does not support 16 bits per colour component either. • Forms: the usage of forms has passed all tests.
• Shading and transparency: shadings worked in most of the tests, but it failed on one case with radial shading. Transparency passed the tests where the transparancies were not layered upon each other. • Graphics state: saving and restoring the graphics state worked as
intended in all of the tested PDF files.
• Patterns: patterns did in some of the tests get the wrong resolution and they could change layout depending on the zoom level. In most cases, pattern worked as expected.
• Filters: all regular filters except the JPXDecode filter were tested and worked as intended. The JPXEncode and the Crypt filter are not supported.
• Encryption: decryption of documents encrypted with the RC4 algo-rithm passed all tests. Encryption with AES is not supported.
5.4
Comparisons
The pre-installed PDF viewer on Symbianˆ3 devices is Adobe Reader. In this section, a comparison between PDF Eagle and Adobe Reader was done in the most important areas. Along with the release of Symbianˆ3 Anna, a new version of Adobe Reader was installed. The comparison was done with this version (10.0.245).
5.4. COMPARISONS
5.4.1
Compatibility
Figure 5.2 shows the differences between PDF Eagle and Adobe Reader when viewing a PDF file containing a lot of lines and areas. The brown circular lines are rendered too thick in PDF Eagle. In text rendering, very small text is easier to read in PDF Eagle. Otherwise, no difference in text rendering can be noted.
(a) PDF Eagle (b) Adobe Reader
Figure 5.2: A comparison between PDF Eagle and Adobe Reader viewing a map over Link¨oping.
On the other hand, more advanced graphical features such as shadings, transparency and patterns are most often handled correctly on PDF Eagle. Adobe Reader supports some shadings and transparency, but shadings are rendered in low resolutions and sometimes rendered with a single colour. Transparency and patterns are rendered correctly except for some of the more advanced cases. A comparison of the shading and transparency ren-dering between PDF Eagle and Adobe Reader can be seen in Figure 5.3. Adobe Reader claims to have encryption support, but all tries to open an encrypted PDF file was met with an error dialog which tells the user that it was unable to open a password protected file. PDF Eagle successfully opens and shows PDF files encrypted with the RC4 algorithm.
Neither of Adobe Reader or PDF Eagle has support for interactive forms or annotations.
CHAPTER 5. ANALYZING RESULTS
(a) PDF Eagle (b) Adobe Reader
Figure 5.3: A comparison between PDF Eagle and Adobe Reader view-ing the manual of PDF Eagle, a document containview-ing shadview-ings and trans-parency.
5.4.2
Speed
To measure the speed of the rendering three types of PDF files were selected. The selected types were 10 PDF files with text only, 10 files with images only and the last type was one large map with hundreds of thousands of objects. On Symbianˆ3, these were opened in both PDF Eagle and Adobe Reader and the time were measured with a stop watch until the first page were completely rendered. The average opening time were calculated and the result can be seen in the table below.
Type PDF Eagle Adobe Reader Text only 8 s 5 s
Images only 9 s 6 s Map 91 s 70 s
An uncached PDF file consisting of a lot of objects is rendered about one third faster in Adobe Reader. The different levels of caching in the applica-tions once a PDF file has been opened makes it hard to give exact numbers as a cache hit significantly decreases the time it takes to show a page, but overall Adobe Reader has a faster rendering engine.
5.5. MEETING THE REQUIREMENTS
5.4.3
User interface
The development of the user interface was not part of the work for this thesis but as it is a vital part of the PDF Eagle application it provides a justification to why this work was needed. It was developed by VISIARC at the time of this thesis.
The user interface in PDF Eagle is responsive, with pinch zoom and almost no locking of the screen at any time. The user interface of the latest version of Adobe Reader implements the use of the touch screen to navigate and pinch zoom, similar to PDF Eagle. When navigating, it does however lock the screen from time to time.
PDF Eagle also provides a smart column zoom feature, which Adobe Reader does not have.
5.5
Meeting the requirements
In this section it is checked if the work of the master thesis meets the re-quirements which were set up in the beginning of the work.
In summary, all of the minimum requirements have been met, but none of the optional requirements are completed. Below is a list that summarizes the completed requirements.
1. The requirement was to implement a stand-alone PDF viewer that could rasterize pages. PDF Eagle is a working stand-alone PDF viewer for sale in the Nokia store since late October 2011.
2. Requirement two was to do a working implementation of the PDF to text functionality. The PDF to text utility converts and displays the text correctly for the test PDF files.
3. It should be possible to index PDF files for searching. The text from the PDF to text functionality can be stored as a search index along with positional data.
4. The requirement was to analyze the possibility of incrementally send-ing PDF pages and server-side rasterization. A design of how to in-crementally send PDF pages from a server to a client was done and tested. Suggestions on how to decide if and when the server shall rasterize a page were also done.
