open pdf file c# : How to add text to pdf file control application platform web page azure wpf web browser 11_07530-part383

MTR110043 
MITRE TECHNICAL REPORT 
A Comparative Study of  
PDF Generation Methods: 
Measuring Loss of Fidelity When 
Converting Arabic and Persian 
MS Word Files to PDF
Contract No.: W15P7T-11-C-F600 
Project No.: 0711G01Z-HB 
Approved for Public Release. 
Distribution Unlimited. 
Case No. 11-0753. 
©2011 The MITRE Corporation. 
All Rights Reserved.
 
Paul M. Herceg 
Catherine N. Ball 
February 17, 2011 
 
Approved for Public Release; Distribution Unlimited 
Case # 11-0753
How to add text to pdf file - insert text into PDF content in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
XDoc.PDF for .NET, providing C# demo code for inserting text to PDF file
add text pdf acrobat professional; how to add text boxes to pdf
How to add text to pdf file - VB.NET PDF insert text library: insert text into PDF content in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Providing Demo Code for Adding and Inserting Text to PDF File Page in VB.NET Program
adding text to pdf in preview; how to insert text into a pdf file
iii 
Abstract 
Converting files to Portable Document Format (PDF) is popular due to the format’s many 
advantages. For example, PDF allows an author to control or preserve the rendering of a digital 
document, distribute it to other systems, and ensure that it displays in a viewer as intended.  
From the perspective of Human Language Technology (HLT), however, PDFs are problematic. 
PDF is a display-oriented digital document format; the point of PDF is to preserve the 
appearance of a document, not to preserve the original electronic text. We observed errors in 
PDF-extracted text indicating that either the PDF generator or extractor, or both, mishandled the 
document structure, character data, and/or entire textual objects. And we learned that other HLT 
researchers reported data loss when extracting electronic text from PDFs. This motivated further 
study of digital document data exchange using PDFs.
MITRE conducted an exploratory study of data exchange using PDF in order to investigate the 
data loss phenomenon. We limited our study to Middle Eastern electronic text: specifically 
Arabic and Persian. The study included a test for scoring PDF generation methods—(a) using a 
common, best-practice setup to generate PDFs and extract text, and (b) using character accuracy 
to quantify the quality of PDF-extracted text. We ranked 8 methods according to the resulting 
accuracy scores. The 8 methods map to 3 core PDF generation classes. At best, the Microsoft 
Word class resulted in 42% Overall Accuracy. Best scores for the PDFMaker and Acrobat 
Distiller/PScript5.dll classes were 95% and 96%, respectively. 
This paper explains our tests and discusses the results, including evidence that using PDF for 
data exchange of typical Arabic and Persian documents results in a loss of important electronic 
text content. This loss confuses human language technologies such as search engines, machine 
translation engines, computer-assisted translation tools, named entity recognizers, and 
information extractors. 
Furthermore, most of the spurious newlines, spurious spaces in tokens, spurious character 
substitutions, and entity errors observed in the study were due to the PDF generation method, 
rather than the PDF text extractor. So, using a common configuration to convert reliable 
electronic text to PDF for data exchange causes irretrievable loss of electronic text on the 
receiving end.  
Keywords: Digital Documents, File Conversion, Reliable Electronic Text, Human Language 
Technology, Portable Document Format, PDF, Microsoft Word, DOCX, Arabic, Persian, 
Character Error Rate, Data Exchange 
VB.NET PDF Password Library: add, remove, edit PDF file password
This VB.NET example shows how to add PDF file password with access permission setting. passwordSetting.IsAssemble = True ' Add password to PDF file.
how to add text to a pdf document using reader; how to add text to a pdf in acrobat
C# PDF Password Library: add, remove, edit PDF file password in C#
This example shows how to add PDF file password with access permission setting. passwordSetting.IsAssemble = true; // Add password to PDF file.
how to add a text box to a pdf; how to add text to a pdf file
iv 
Table of Contents 
Abstract .......................................................................................................................................... iii
 
1. Introduction ................................................................................................................................. 1
 
2. Method ........................................................................................................................................ 2
 
2.1. Snippets of Electronic Text Reside in PDF Language Commands as Font Codes ............................ 3
 
2.2. Arabic and Persian Electronic Text is Coded in Contextual Forms in a PDF ................................... 4
 
2.3. Test Documents ................................................................................................................................. 4
 
2.4. Conversion to Microsoft Word Format .............................................................................................. 6
 
2.5. PDF Generation ................................................................................................................................. 6
 
2.6. PDF Text Extraction .......................................................................................................................... 7
 
2.7. Scoring ............................................................................................................................................... 7
 
2.8. Data Analysis ..................................................................................................................................... 8
 
3. Results and Discussion ............................................................................................................... 9
 
3.1 Results: Scores and Ranking ............................................................................................................... 9
 
3.2. Discussion: Scores and Ranking ...................................................................................................... 12
 
3.3. Results: Acrobat Distiller/PScript5.dll PDF Generation Class Errors ............................................. 13
 
3.4. Discussion: Acrobat Distiller/PScript5.dll PDF Generation Class Errors ....................................... 14
 
3.5. Results: PDFMaker PDF Generation Class Errors .......................................................................... 17
 
3.6. Discussion: PDFMaker PDF Generation Class Errors ..................................................................... 18
 
3.7 Results: Microsoft Word PDF Generation Class Errors ................................................................... 18
 
4. Conclusion ................................................................................................................................ 18
 
Acknowledgments......................................................................................................................... 20
 
References ..................................................................................................................................... 20
 
C# PDF File & Page Process Library SDK for C#.net, ASP.NET, MVC
Read: PDF Text Extract; C# Read: PDF Image Extract; C# Write: Insert text into PDF; C# Write: Add Image to PDF; C# Protect: Add Password
add text field pdf; adding text box to pdf
VB.NET PDF Text Extract Library: extract text content from PDF
this advanced PDF Add-On, developers are able to extract target text content from source PDF document and save extracted text to other file formats through VB
how to insert text in pdf using preview; adding text fields to pdf
1. Introduction 
Converting files to PDF is a popular practice for exchanging digital documents. Converting a 
document to PDF offers many advantages. The PDF can be viewed using the widely available 
Adobe Reader or other readers, without any need for the application that created the original file; 
the PDF can preserve the look and feel of the original document; and the PDF can preserve the 
integrity of the original document, in the sense that a PDF file is less easily modified than (say) a 
Microsoft Word document. 
From the perspective of Human Language Technology (HLT), however, exchanging digital 
documents via PDF is highly problematic. Herceg and Ball (2010) explain that HLT applications 
such as machine translation and information extraction require reliable electronic text as input, 
and that extracting text from a file is one of the first steps in a document processing pipeline. 
Extracting reliable electronic text from PDFs is fraught with difficulties, particularly for foreign 
script languages (Herceg & Ball, 2010, p. 3). Issues arise because PDF is a display-oriented 
document format; the point of PDF is to preserve the appearance of a document, not to preserve 
the original electronic text. 
The PDF file format is designed to provide instructions for painting (or rendering) document 
objects on one or more virtual document pages (Adobe, 2008, p. vii; King, 2008; Powley et al., 
2009, p. 3). The process of converting to PDF Language text rendering instructions must be 
reversed to derive the original source electronic text.  
The complexity of reversing this conversion makes extracting the electronic text challenging. 
The text rendering instructions use strings of character codes, denoting glyphs (in a font 
encoding), from which electronic text can be derived only under certain conditions (Adobe, pp. 
251, 292).
1
King (2008) and Carrier (2009) explain the following: 
A glyph’s character code may be the code point value in a standard encoding such as 
ASCII or Unicode, but this is not always the case—for example, the character codes for 
ligatures in a Latin font, and the character codes for glyphs in an Arabic font 
Extracting text from a PDF requires decoding strings of character codes via a character 
mapping table (which may or may not be present), reforming words (e.g., words that 
were broken into two or more chunks, or that were hyphenated and broken across two 
lines), and reconstituting newlines and reading order based on spatial or structural 
information 
Furthermore, extracting text from a PDF requires normalizing decomposable Unicode 
characters, and, converting right-to-left language from display order into storage order, 
while not affecting left-to-right components 
Powley, Dale, and Anisimoff (2009) experienced these complexities firsthand while trying to 
perform information extraction research on PDFs of English-language academic papers (p. 3). 
They mention tests of a number of commercial and open source text extractors. None were able 
to generate reliable electronic text acceptable for their research. 
1
glyph is a particular shape of a given letter or character. 
C# PDF Text Extract Library: extract text content from PDF file in
How to C#: Extract Text Content from PDF File. Add necessary references: RasterEdge.Imaging.Basic.dll. RasterEdge.Imaging.Basic.Codec.dll.
add text box in pdf; adding text to a pdf in preview
C# PDF insert image Library: insert images into PDF in C#.net, ASP
using RasterEdge.Imaging.Basic; using RasterEdge.XDoc.PDF; Have a try with this sample C#.NET code to add an image to the first page of PDF file.
adding text to pdf file; how to add text to a pdf in preview
We, also, have observed errors in PDF-extracted text indicating that either the PDF generator or 
text extractor, or both, mishandled the document structure, character data, and/or entire textual 
objects. We are not aware of any research that has sufficiently measured this phenomenon. 
PDFs may be generated by a variety of methods, such as printing to PDF, converting a document 
to PDF using Adobe Acrobat Professional, converting a document to PDF using Microsoft 
Word, and so on. We believe that the amount of mishandling introduced by each of these 
methods varies, and that it would be valuable to rank these techniques in order of accuracy (e.g., 
best accuracy at the top of the list). Furthermore, we believe that such data loss may happen 
more frequently with non-western languages. 
MITRE undertook to rank a number of PDF generation methods by scoring the accuracy of PDF 
text extraction. For the study, we used a test pipeline from plain text, to Microsoft Word format, 
to PDF, to PDF-extracted plain text—where we held all components constant and systematically 
manipulated the document language, the PDF generation method, and the Unicode normalization 
treatment. We sought to design the test to be economical. Hence, we limited our focus to (a) 
Arabic and Persian; (b) methods that present themselves on a PC with Microsoft Windows XP, 
Microsoft Word, and Adobe Acrobat; (c) a small test data set; and (d) using off-the-shelf tools to 
calculate accuracy. 
2. Method 
In this section, we discuss the details of the procedure we used to achieve the ranking of PDF 
generation methods. Figure 1 shows a notional view of the test—a document processing pipeline. 
It begins with an original plain text document in Unicode UTF-8 encoding. Microsoft Word 
converts this document to its proprietary .DOCX format. One of a number of PDF generation 
methods converts the file to PDF. A PDF text extractor delivers the content as a PDF-extracted 
plain text file (e.g., UTF-8). Finally, a scoring tool automatically scores the character accuracy of 
the PDF-extracted document against the original document.  
MS Word 
Document
PDF
Extracted 
Text 
Document
Original 
Text 
Document
Score
Accuracy
Apply a 
PDF
Generation
Method
Extract
Text
32 Combinations:
2 languages
8 PDF generation methods
1 Extractor
2 Treatments to the 
PDF‐extractedtext
Figure 1. Notional view of the test. 
We ran the test 32 times, introducing a slight variation in the configuration of components with 
each run. Variations included two Middle Eastern languages, eight PDF generation methods, and 
two treatments to the extracted text. We used the same text extractor for all runs.  
The original plain text documents we used in our test are not real-world documents. Rather, they 
are space-delimited lists of tokens (i.e., words and word phrases), symbols, and entities that were 
VB.NET PDF File Compress Library: Compress reduce PDF size in vb.
Also able to uncompress PDF file in VB.NET programs. Offer flexible and royalty-free developing library license for VB.NET programmers to compress PDF file.
add text to pdf in preview; add text box to pdf file
VB.NET PDF insert image library: insert images into PDF in vb.net
try with this sample VB.NET code to add an image As String = Program.RootPath + "\\" 1.pdf" Dim doc New PDFDocument(inputFilePath) ' Get a text manager from
adding text to pdf form; add text box to pdf
carefully fabricated for the purpose of the test. Before we discuss the process the team used to 
develop these text documents in each language, we need to convey background about electronic 
text in the PDF file format. 
2.1. Snippets of Electronic Text Reside in PDF Language Commands as Font Codes 
Simply put, electronic text in a PDF file resides in PDF Language statements (or commands) that 
specify sequences of font codes as arguments (Adobe, 2008, p. 251).
2,3
We use the non-standard 
term font code for the purpose of simplifying the discussion of PDFs. These font codes are the 
lookup values for a font encoding table, and denote a specific glyph in a font such as Arial or 
Times New Roman.  
Sequences, or strings, of font codes are encoded snippets of electronic text that are limited to the 
length of the widest line of text on a given page. For the Arabic and Persian PDFs we have 
examined, each font code is a 4-byte sequence; hence, font code strings are not readable Arabic 
and Persian. To be clear, Arabic and Persian electronic text in a PDF does not appear as a stream 
of characters in a widely known encoding (e.g., Unicode, CP1256). To be accurate, however, the 
exception is where a string’s font codes represent Latin glyphs (or other glyphs appearing in the 
ASCII character set). In these Latin strings, each font code is a single byte that is the same as the 
ASCII code point for lookup in an ASCII table. These Latin font code strings can be copied from 
their PDF Language context and used as ASCII strings. 
A PDF contains a list of PDF Language commands for rendering the strings of font codes (i.e., 
textual glyphs), and/or other document objects, on one or more electronic document pages. These 
commands have their roots in typography, so, to understand the PDF Language, one must have at 
least a rudimentary understanding of typography. Only a few of the typographic commands, 
called text showing operators, can hold strings of font codes as arguments. How these operators 
behave when rendering each textual glyph on a Cartesian coordinate system is based on the 
typographic settings configured or re-configured with a larger set of typographic commands: text 
state operators, text positioning operators, and text object operators. The PDF Language is 
cryptic to the untrained eye. To get a sense of its complexity: a PDF may contain several hundred 
typographic commands to render a simple paragraph of 100 words.  
Often the typographic commands for painting strings of font codes (i.e., strings of electronic 
text) appear out of their natural reading order in the PDF Language code. Also, each entire line 
of text may be dispersed among several text showing operators, for which each font code string 
is a single token/word, part of a token/word, or merely a single character of a token/word. 
Because glyphs are rendered on a page’s coordinate system, there really is no requirement that 
the order of the text showing operators reflect reading order (also known as text flow ). The 
degree to which electronic text is dispersed among multiple PDF commands depends on the 
method responsible for generating the PDF. 
2
Font code is short for font character code
3
Technically speaking, the PDF specification uses the term character code rather than font code. However, using 
the term character code in this paper would make it difficult for readers to differentiate between (a) character codes 
that are font encoding values and (b) character codes that are code points in a widely known standard encoding (e.g., 
Unicode). Furthermore, using the term character code here would introduce undue complexity because the PDF 
specification actually gives three definitions of the term character code, and states that the meaning varies 
depending on context (Adobe, 2008, p. 6). 
C# PDF File Split Library: Split, seperate PDF into multiple files
page of your defined page number which starts from 0. For example, your original PDF file contains 4 pages. C# DLLs: Split PDF Document. Add necessary references
adding text to a pdf in acrobat; how to add text to pdf file with reader
VB.NET PDF File Merge Library: Merge, append PDF files in vb.net
by directly tagging the second PDF file to the target one, this PDF file merge function VB.NET Project: DLLs for Merging PDF Documents. Add necessary references
how to add text to a pdf document; adding text to a pdf
For Arabic and Persian, there is yet another nuance to the font code strings. In the Arabic and 
Persian PDF files we examined, each string of font codes is stored in reverse reading order—
contrary to the way Unicode text is stored. 
2.2. Arabic and Persian Electronic Text is Coded in Contextual Forms in a PDF 
Arabic and Persian electronic text in a PDF is coded in its contextual forms. For Arabic and 
Persian, each letter of the alphabet can take on a number of contextual forms (i.e., different 
shapes)—isolated, initial, medial, and final. As we already mentioned, each code in a string of 
font codes indicates a particular glyph shape, which is looked up in a font encoding table (e.g., 
Arial, Times New Roman). For most of the letters of the Arabic and Persian alphabets, each form 
is associated with a different glyph shape in a given font encoding table. An Arabic or Persian 
font must at least support the basic contextual shapes, but it may include even more shapes. The 
combination of a character with a diacritic may add yet another glyph shape. The special 
additional characters in Arabic and Persian may add many more glyph shapes. 
2.3. Test Documents 
With this background on electronic text in PDFs, and, in particular, Arabic and Persian, we turn 
to the process that our team used to develop the Arabic and Persian test documents. Our test 
documents take into account all of the contextual forms, the character and diacritic combinations, 
and the special characters used most widely in each of the languages. Also, the documents, 
although fabricated, incorporate words in which these contextual forms occur. 
We performed the following steps for each language. We developed a list of the canonical 
Unicode code points typically used in the given language (Table 1 and Table 2). Then, we 
applied an understanding of the language to expand this list to the various glyph shapes typically 
rendered by each code point.
4,5
Google’s language-specific search allowed us to download 
Microsoft Word documents in the language. Detailed searching within these files allowed us to 
generate a list of tokens representing all of the glyph shapes—one token for each glyph shape.
6,7
4
Arabic numerals used in the West were not included. 
5
Some code points were added later. We added ARABIC TATWEEL ( 
ـ
U+0640) and ARABIC FATHATAN 
 
ً
U+064B) to the Arabic and Persian lists. And we added ARABIC SHADDA (  
ّ◌
U+0651) to the Persian list. 
6
Most of the tokens are single words, while others are more than one word. We could achieve the study’s objective 
regardless of the number of words per token. 
7
At this point in the process we had a total of 127 code point and contextual form combinations for Arabic, and 146 
combinations for Persian. These counts do not include the ZERO WIDTH NON-JOINER. 
Table 1. Unicode Code Points for Developing the Arabic Test Document 
All canonical code points for the 28 letters of the alphabet 
ARABIC LETTER HAMZA (
ء
U+0621) and the following alphabetic 
characters: 
ARABIC LETTER ALEF WITH HAMZA BELOW (
إ
U+0625),  
ARABIC LETTER ALEF WITH HAMZA ABOVE (
أ
U+0623),  
ARABIC LETTER WAW WITH HAMZA ABOVE (
ؤ
U+0624),  
ARABIC LETTER YEH WITH HAMZA ABOVE (
ئ
U+0626) 
The following modified letters:  
ARABIC LETTER ALEF WITH MADDA ABOVE (
آ
U+0622),  
ARABIC LETTER TEH MARBUTA (
ة
U+0629), 
ARABIC LETTER ALEF MAKSURA (
ى
U+0649) 
The ZERO WIDTH NON-JOINER (U+200C) 
Arabic-Indic Digits 
٠
(U+0660), 
١
(U+0661), 
٢
(U+0662), 
٣
(U+0663), 
٤
(U+0664), 
٥
(U+0665), 
٦
(U+0666), 
٧
(U+0667), 
٨
(U+0668), 
٩
(U+0669) 
Table 2. Unicode Code Points for Developing the Persian Test Document 
All canonical code points for the 32 letters of the alphabet, including the 
following four letters unique to the Persian alphabet: 
ARABIC LETTER PEH (
پ
U+067E), 
ARABIC LETTER TCHEH (
چ
U+0686), 
ARABIC LETTER JEH (
ژ
U+0698), 
ARABIC LETTER GAF (
گ
U+06AF) 
ARABIC LETTER HAMZA (
ء
U+0621) and the following alphabetic 
characters: 
ARABIC LETTER ALEF WITH HAMZA ABOVE (
أ
U+0623), 
ARABIC LETTER WAW WITH HAMZA ABOVE (
ؤ
U+0624), 
ARABIC LETTER YEH WITH HAMZA ABOVE (
ئ
U+0626), 
ARABIC LETTER HEH WITH YEH ABOVE (
ۀ
U+06C0) 
The commonly used Arabic substitutions for Persian characters:  
ARABIC LETTER YEH (
ي
U+064A), 
ARABIC LETTER KAF (
ك
U+0643), 
ARABIC LETTER ALEF MAKSURA (
ى
U+0649) 
The ZERO WIDTH NON-JOINER (U+200C) 
Arabic-Indic Digits 
٠
(U+0660), 
١
(U+0661), 
٢
(U+0662), 
٣
(U+0663), 
٤
(U+0664), 
٥
(U+0665), 
٦
(U+0666), 
٧
(U+0667), 
٨
(U+0668), 
٩
(U+0669) 
Eastern Arabic-Indic Digits 
٠
(U+06F0), 
١
(U+06F1), 
٢
(U+06F2), 
٣
(U+06F3), 
۴
(U+06F4), 
۵
(U+06F5), 
۶
(U+06F6), 
٧
(U+06F7), 
٨
(U+06F8), 
٩
(U+06F9) 
According to guidance from the Unicode Consortium, this list of Unicode code points includes 
only those from the canonical range, with the exception of the ZERO WIDTH NON-JOINER. It 
does not include Unicode presentation forms.
8
The Unicode Consortium (2011) explains: 
Data files should only include the canonical range 
Presentation forms merely exist for historical reasons 
It is the responsibility of software using plain text data to render applicable Arabic 
ligatures and contextual forms 
8
Specifically, the presentation forms are Arabic Presentation Forms A (U+FB50 to U+FDFF) and Arabic 
Presentation Forms B (U+FE70 to U+FEFF). 
We considered each digit to be a token and added it to the list. We also added Allah (
, U+0627 
U+0644 U+0644 U+0647) and a short list of date and measurement entities.
9
We concatenated all of the tokens on the list, delimiting each with a space, and exported the 
document (Microsoft Word format) to plain text (UTF-8). As a final check, we validated that 
conversions to Microsoft Word format, and back again to UTF-8, generated an identical plain 
text UTF-8 file.  
Following the process above, we generated a single UTF-8 test document for Arabic and a single 
UTF-8 test document for Persian.  
2.4. Conversion to Microsoft Word Format 
With the original plain text UTF-8 files in hand, we initiated the document processing pipeline. 
For each original plain text file, we performed the following: 
Opened the UTF-8 file in Microsoft Word 2007 SP2 
Changed the font to 16-point Arial 
On the Home Tab, in the Paragraph Group, clicked the Right-to-Left Text direction 
button 
Saved the .DOCX file (i.e., Microsoft Word file) 
2.5. PDF Generation 
Next, we converted each .DOCX file to PDF. We constrained the test to the 8 PDF generation 
methods that can be performed on a PC with Windows XP SP3, Microsoft Word 2007 SP2, and 
Adobe Acrobat 9 Professional (v.9.4.1). Correspondence with Adobe Systems confirmed that 
these 8 compose an exhaustive list of such PDF generation methods:  
1.  Open the .DOCX file in Acrobat; click File > Save As; click Save (to PDF) 
2.  Open Acrobat; click File > Create PDF > From File; specify the .DOCX file; click Open; 
click Save (to PDF) 
3.  Open the .DOCX file in Word; print it to the Adobe printer (i.e., virtual printer) 
4.  Open the .DOCX file in Word; click the Microsoft Office Button; click 
Save As > Adobe PDF 
5.  Open the .DOCX file in Word; click the Microsoft Office Button; click 
Save As > PDF or XPS; click Publish 
6.  Open the .DOCX file in Word; click the Acrobat tab; click Create PDF 
7.  Ensure the default printer is set to the Adobe printer (i.e., virtual printer); right-click the 
.DOCX file in Windows Explorer; click Print 
8.  Right-click the .DOCX file in Windows Explorer; click Convert To Adobe PDF; click 
Save 
Before applying these methods, we prepared Adobe Acrobat preferences. We ensured that the 
Adobe Printer “Printing Preferences” were set to default, and we set our default printer to the 
Adobe PDF virtual printer. In Microsoft Word, we ensured the Adobe Acrobat PDFMaker 
9
Specifically, we added 6 entities to the Arabic list and 5 entities to the Persian list. 
preferences were set to defaults, except for the following setting: on the PDFMaker settings tab, 
we checked Create PDF/A-1a:2005 compliant file. This setting is intended to ensure that the 
structure and semantics of the original digital document are preserved. We did this to give the 
PDFMaker-related PDF generation methods the best possible chance of preserving the electronic 
text of our documents. 
2.6. PDF Text Extraction 
We held the PDF text extractor constant throughout the study, and we ensured that we used a 
best-of-breed extractor. Several text extractors are available, but performance varies widely 
(Powley, et al., 2009, p. 3). We used PDF Box because it includes a best-of-breed extractor that 
can be invoked from the command line (Apache, 2010). 
Specifically, we used the following command line: 
java -Dglyphlist_ext="glyphlist-ext.txt" -jar "c:\progra~1\pdfbox\pdfbox-app-
1.3.1.jar" ExtractText -sort -encoding UTF-8 output.txt 
This command line specifies a glyph list file. Although a glyph list file is available directly from 
Adobe Systems, we used a glyph list file supplied from a collaborating group that optimized the 
glyph list for Arabic and Persian. At the time of this writing, the Adobe list is available for 
download at http://partners.adobe.com/public/developer/en/opentype/glyphlist.txt 
2.7. Scoring 
The goal of the study was to rank PDF generation methods based on how well a PDF-extracted 
text document compares to its original plain text document. Our past collaboration with 
commercial content extraction vendors indicated that there are no standard measures or practices 
for quantifying the performance of text extraction. Yet the task of extracting text from a file is 
comparable to the task of applying optical character recognition (OCR) to a document image. 
Furthermore, character error rate (CER) is well established for scoring OCR performance. So, we 
decided to apply CER to scoring the quality of PDF-extracted text. 
Fortunately, there are open source tools available for scoring CER and analyzing OCR output. 
We used the University of Nevada Las Vegas (UNLV) Information Science Research Institute 
(ISRI) Analytic Tools for OCR Evaluation v.5.1 and the UNLV ISRI OCR Frontiers Toolkit 
v.1.0 to score the character error (UNLV, 1996; Rice & Nartker, 1996; UNLV, 1999; Bagdanov, 
Rice, & Nartker, 1999). These include tools for dealing with Unicode data—the format of our 
Arabic and Persian original plain text, and Arabic and Persian PDF-extracted text.
10,11
The 
Accuracy tool generates the Accuracy score that we used to rank the PDF generation methods, 
and generates a number of other statistics that are useful for analyzing character errors. The 
Synctext tool provides error position information. 
The UNLV tools allow us to compare some PDF-extracted text output—the hypothesis—against 
some original plain text document—the reference. UNLV’s definition of Accuracy is as follows: 
given a reference and a hypothesis, 
ܣܿܿݑݎܽܿݕ ൌ
஼௛௔௥௔௖௧௘௥௦ିா௥௥௢௥௦
஼௛௔௥௔௖௧௘௥௦
, where Characters is the total 
10
Ideally, we would also want to score word error rate (or token error rate), but the UNLV tool documentation states 
that the word accuracy tools define a word as a sequence of one or more ASCII or Latin1 letters. 
11
These UNLV tools convert Unicode to and from a format called Extended ASCII
Documents you may be interested
Documents you may be interested