open pdf in word c# : How to delete text from pdf control software system web page winforms azure console HPL-2003-2590-part320

Creating Digital Libraries:  Content Generation 
and Re-Mastering 
Steven J. Simske, Xiaofan Lin 
Imaging Systems Laboratory  
HP Laboratories Palo Alto 
HPL-2003-259 
December 8
th
, 2003*
E-mail: {steven.simske, xiaofan.lin}@hp.com 
zoning 
analysis, 
quality 
assurance, 
TIFF, OCR, 
PDF, 
meta-algorithmics 
This paper has two main goals: to describe the automatic creation of 
a digital library and to provide an overview of the meta-algorithmic 
patterns that can be applied to increase the accuracy of its creation. 
Automating the creation of useful digital libraries-that is, digital 
libraries affording searchable text and reusable ("re-purposable ") 
output-is  a complicated  process,  whether  the original  library  is 
paper-based or already available in electronic form. In this paper, 
we outline the steps involved in the creation of a deployable digital 
library (> 1.2 x 10
pages) for MIT Press, as well as its implications 
to other aspects of digital library creation, management, use and 
repurposing.  Input,  transformation,  information  extraction,  and 
output processes are considered in light of their utility in creating 
layers of content. Interestingly, in some aspects, scanning directly 
from paper offers extra opportunities for error-checking through 
feedback-feedforward combination. Strategies for quality assurance 
(QA) at the document, chapter and book level are also discussed 
We emphasize  the use  of meta-algorithmic  design  patterns for 
application towards improving the content generation, extraction 
and re-mastering. This approach also increases the ease with which 
modules and algorithms are added to and deprecated  from the 
system. 
* Internal Accession Date Only 
Approved for External Publication 
To be published in and presented at the International Workshop on Document Image Analysis for Libraries 
(DIAL'04), 23-24 January 2004, Palo Alto, California 
ã Copyright IEEE 2003 
How to delete text from pdf - delete, remove text from PDF file in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Allow C# developers to use mature APIs to delete and remove text content from PDF document
how to delete text in a pdf file; how to erase in pdf text
How to delete text from pdf - VB.NET PDF delete text library: delete, remove text from PDF file in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Programming Guide to Delete Text from PDF File
pdf text remover; how to remove text watermark from pdf
Creating Digital Libraries: Content Generation and 
Re-Mastering 
Steven J. Simske 
Xiaofan Lin 
Imaging Systems Laboratory 
Hewlett-Packard Laboratories 
E-mail: {steven.simske, xiaofan.lin}@hp.com 
December 1, 2003 
ABSTRACT 
This paper has two main goals: to describe the automatic creation of a digital library and to provide an 
overview of the meta-algorithmic patterns that can be applied to increase the accuracy of its creation.  
Automating the creation of useful digital libraries—that is, digital libraries affording searchable text and 
reusable (“re-purposable”) output—is a complicated process, whether the original library is paper-based 
or already available in electronic form.  In this paper, we outline the steps involved in the creation of a 
deployable digital library (>1.2 x 10
6
pages) for MIT Press, as well as its implications to other aspects of 
digital library creation, management, use and repurposing.  Input, transformation, information extraction, 
and output processes are considered in light of their utility in creating layers of content.  Interestingly, in 
some aspects, scanning directly from paper offers extra opportunities for error-checking through feedback-
feedforward combination.  Strategies for quality assurance (QA) at the document, chapter and book level 
are also discussed.  We emphasize the use of meta-algorithmic design patterns for application towards 
improving the content generation, extraction and re-mastering.  This approach also increases the ease with 
which modules and algorithms are added to and deprecated from the system. 
Keywords: Zoning Analysis, Quality Assurance, TIFF, OCR, PDF, Meta-Algorithmics
1  Introduction 
In this paper, we introduce the digital library generation performed on the MIT Press out-of-print book 
collection.  We then present the design and deployment methods for its generation, followed by a 
discussion of the quality assurance techniques used.  Next, we discuss the data-related considerations: how 
content is extracted from scanned document images; how these documents are digitally re-mastered; and 
finally how the use of meta-algorithmic techniques and patterns benefits the generation of a digital library.  
Finally, we report on the output formats used, and finish up with a discussion and conclusions section. 
Type of File 
Resolution (ppi) 
Bits/pixel 
File Size (per page) 
1. Black text only 
600 
4.2 MB 
2. Grayscale only 
400 
15 MB 
3. Color 
400 + 200 
8 + 24 
26 MB 
Table 1. Bit depth specifications for the MIT Press/Cognet [1,2] project. 
The authors and their colleagues derived and published a digital library that was the front-end for both a 
large-scale print-on-demand system for MIT Press [1] and for the MIT cognitive network, or CogNet [2].  
Users access this digital library in one of two ways: either by buying a “classic” book from MIT Press [1] 
or by signing up for membership in the Cognet community [2].  These publishing assets consisted of 4000 
books, mostly scientific/technical, published before c. 1990 and generally in good condition.  This system 
was used to convert raster scanned documents (saved, originally, as TIFF files) into printable and web-
readable files (PDF was the preferred output).  4000 out-of-print books were band-sawed (to remove their 
covers) and then the pages were scanned according to the specifications shown in Table 1. For files that are 
VB.NET PDF Page Delete Library: remove PDF pages in vb.net, ASP.
›› VB.NET PDF: Delete PDF Page. VB.NET PDF - How to Delete PDF Document Page in VB.NET. Visual Basic Sample Codes to Delete PDF Document Page in VB.NET Class.
delete text pdf files; how to edit and delete text in pdf file online
C# PDF Page Delete Library: remove PDF pages in C#.net, ASP.NET
Page: Delete Existing PDF Pages. |. Home ›› XDoc.PDF ›› C# PDF: Delete PDF Page. C#.NET PDF Library - Delete PDF Document Page in C#.NET.
how to delete text from pdf with acrobat; delete text pdf preview
known to be (black) text-only, 600 ppi (pixels/inch, which is the same in x- and y-directions for all values 
shown) 1-bit data suffices.  For pages with grayscale regions (black and white photos, etc.), 400 ppi, 8-bit 
data is used.  For pages containing color, an additional 200 ppi, 24-bit file is necessary.  To simplify the 
scanning specifications, we did not use the first option (600 ppi, 1-bit). 
The original specifications were three-fold: text-only pages were to be scanned at 600 ppi, 1-bit; 
grayscale-only (text, drawings, black and white photos, no color regions) pages were to be scanned at 400 
ppi, 8-bit; and pages with one or more color regions were to be scanned twice—once at 400 ppi, 8-bit and 
again at 200 ppi, 24-bit.  Very few pages (<1%) contained color regions.  Additionally, because the 
scanning was performed off-shore (in the Barbados and in Ciudad Obregón, Mexico), the specifications 
were further simplified:  400 ppi, 8-bit scanning was used for all pages, and a second—200 ppi, 24-bit—
scan was made for pages with one or more color regions on it.  400 ppi was chosen to catch the fine detail 
in small font—e.g. 6-point—and line drawings and graphics.  A bit depth of 8 was chosen to reduce storage 
overhead. 
Figure 1.  Sample original document image as scanned.  Note the poor contrast in the text. 
In this paper, we also report how “meta-algorithmics” [7,8] and the corresponding meta-algorithmic 
design patterns were used to increase the accuracy of the output generated in the digital library creation.  
By meta-algorithmics we mean “meta-“ as “beyond; transcending; more comprehensive”—as a practical 
matter, we define meta-algorithmics as the improvement of algorithmic output through the use of 
combination.  We say more about this below. 
More than 1.2 million pages were scanned.  Auto-exposure (making sure the white and black points of 
the input are close to 255 and 0, respectively) and gamma correction (a factor of 1.8 was employed—this 
was computed by an auto-gamma detection algorithm that has shipped with the HP Precision Scan zoning 
VB.NET PDF Text Extract Library: extract text content from PDF
PDF ›› VB.NET PDF: Extract PDF Text. VB.NET PDF - Extract Text from PDF Using VB. How to Extract Text from PDF with VB.NET Sample Codes in .NET Application.
remove text from pdf; how to erase text in pdf online
C# PDF Text Extract Library: extract text content from PDF file in
XDoc.PDF ›› C# PDF: Extract PDF Text. C# PDF - Extract Text from PDF in C#.NET. Feel Free to Extract Text from PDF Page, Page Region or the Whole PDF File.
delete text pdf acrobat; how to delete text from pdf reader
analysis engine since 1996) were used to improve the appearance of the scanned files.  These are standard 
techniques for the treatment of scanned images while they are created, and are usually performed in casual 
scanning by the user with the use of a WYSIWYG user interface-based preview window.  A sample image 
before these corrective steps is shown in Figure 1; its corrected image is shown in Figure 2.  Custom 
software (HP Precision Scan) was then used to analyze these pages, tagging the with the appropriate region 
types (text, drawing, photograph) appropriately classified  for their boundaries  (segmentation), type 
(classification as text, drawing or photograph) and bit-depth (1-bit for text, rules, line drawings, bounding 
rectangles, etc.; 8-bit for gray-scale graphics and photos; and 24-bit for color graphics and photos).  Other 
page segmentation and region classification (“zoning”) engines have been known for 20 years [3], although 
zoning is still an area of research interest [4,5,23,24].  Ours was augmented by a closed-loop feedback 
system [6] in which the output file is closely compared to the input file after each zoning analysis step.  
This helps to minimize the overall error in the automation of the library’s generation: effects on the overall 
error rate are discussed below. 
Figure 2.  Sample original document image in Figure 1 following auto-exposure and gamma 
correction.  Zoning analysis errors were reduced by more than a factor of 2 after these processing 
steps were added. 
In the case of MIT Press, the digital library end user requirements were straightforward:  PDF files with 
searchable text.  The PDFs were backward-compatible with Adobe Acrobat Reader 3.0 for increased reader 
compatibility.  To achieve these user requirements, the following functional modules were required (Table 
2):  (1) TIFF file reading and scaling, in which the original TIFF file is prepared for each of the 
downstream functions [we modified existing code from HP scanning products for this]; (2) zoning analysis, 
in which the regions are formed; (3) OCR engine analysis, in which ASCII/Unicode text is formed using 
C# PDF insert text Library: insert text into PDF content in C#.net
Text to PDF. C#.NET PDF SDK - Insert Text to PDF Document in C#.NET. Providing C# Demo Code for Adding and Inserting Text to PDF File Page with .NET PDF Library.
how to delete text in pdf using acrobat professional; delete text pdf document
C# PDF Text Search Library: search text inside PDF file in C#.net
Text: Search Text in PDF. C# Guide about How to Search Text in PDF Document and Obtain Text Content and Location Information with .NET PDF Control.
how to delete text from a pdf reader; remove text watermark from pdf
the identified text regions in the previous step; (4) clean-up of the OCR using dictionary look-up and 
voting, hyphen removal and other techniques; (5) OCR feedback to zoning analysis; (6) the generation of 
the output PDF files using custom code based on the PDF specification, and (7) the schema-drive 
generation of the output XML files. 
The MIT Press digital library generation was customer-driven.  MIT Press did not have its out-of-print 
books converted to offer a “free” library.  Rather, it was used to support “classic” book sales through print-
on-demand as well as to augment the cognitive network (“CogNet”) that they provide to a community of 
cognitive scientists.  However, our partners at MIT Press were impassive to any advanced work we 
performed using their content insofar as the digital library so generated met their needs.  We will discuss 
some of the additional research performed in creating the MIT Press digital library below.  One such 
research thread, it should be noted, was immediately adopted by the MIT Press for use with their out-of-
print journals.  Thus, the “journal splitting” (splitting a journal comprising multiple articles into its separate 
articles) [16] we performed on the corpus will be an important example in the area of “content re-
mastering”. 
Functional Requirement 
How implemented 
1. TIFF file reading/scaling 
Custom TIFF reading software 
2. Zoning analysis 
HP Precision Scan Pro + QA augmentations 
3. OCR engine loading/analysis 
HP-licensed OCR engine/s 
4. OCR clean-up 
Custom code feeding back to (3.) 
5. OCR feedback to zoning analysis 
Custom code feeding back to (2.) 
6. PDF generation 
Custom code based on the PDF specification 
7. XML generation 
Schema-driven code with custom XML-parser 
Table 2. Functional requirements after appropriate (gamma corrected, auto-exposed) TIFF files with 
correct resolution and bit depth had been captured.  Most of the (C++-based) code was “custom” 
code, to avoid licensing issues and to provide full control of all source code in the project. 
2  Design and Deployment Methods 
The MIT Press digital library creation involved extensive Document Image Analysis (DIA) 
technologies.  The DIA methods we used to achieve the functional requirements listed in Table 2 are 
discussed here.  Where appropriate, we will allude to meta-algorithmic techniques that were used to 
improve the accuracy (if not performance) of the different steps. 
All of the 1.2 x 10
6
pages required for the MIT Press Digital Library creation have been processed.  For 
the purposes of comparing different DIA methods, we supplemented the overall timing and error results, 
which were only broken out on a per-page basis, with specific timing and error results we obtained by 
running different settings within a 700 page sub-corpus.  We will comment on the differences between 
these two sets of data where both exist. 
2.1. DIA methods for the functional requirements in Table 2 
1. TIFF file reading/scaling
. The specifications of the scanned TIFF files were either 400 ppi resolution 
with 8 bits/pixel bit depth; or this in combination with 200 ppi resolution with 24 bits/pixel bit depth (Table 
1).  These specifications were preserved for the PDF generation—that is, the 400x8 raster and, if present, 
200x24 raster were both loaded into memory for later PDF generation.  Scaling was performed to generate 
the raster used for zoning analysis in the next step.  The HP Precision Scan zoning analysis engine performs 
accurately on resolutions between 30-100 ppi—it was designed to handle “preview” data that shows up in a 
user interface (UI) on a PC, so variable-ppi raster input was important.  In a non-UI mode, the HP Precision 
Scan zoning engine uses a 75 ppi raster, since this scales easily from the typical 150 ppi (photos) and 300 
ppi (documents) defaults for scanning.  This gave us some options relating to the trade off between (1) the 
time it takes to perform the scaling, (2) the time it takes to perform the zoning analysis, and (3) the 
accuracy of the zoning analysis.  Since the time for (1) and (2) are relatively equal in length, we decided to 
simplify the scaling by making it an integral factor—this allows simple pixel averaging to obtain the scaled 
C# PDF Convert to Text SDK: Convert PDF to txt files in C#.net
C#.NET PDF SDK - Convert PDF to Text in C#.NET. Integrate following RasterEdge C#.NET text to PDF converter SDK dlls into your C#.NET project assemblies;
remove text watermark from pdf online; how to delete text from a pdf in acrobat
C# PDF metadata Library: add, remove, update PDF metadata in C#.
Allow C# Developers to Read, Add, Edit, Update and Delete PDF Metadata in .NET Project. Remove and delete metadata from PDF file.
pdf text watermark remover; erase text from pdf file
raster.  We chose a factor of 5, since the resulting zoning analysis resolution is 80—close to the default 
value of 75, and thus generally benefiting from extensive Beta-testing (combined “white-box” and “black 
box” testing of the software after the code was functionally complete) performed at this resolution.  The 
difference in performance at 80 ppi compared to 75 ppi is negligible, and the overall combination is clearly 
preferable to other possibilities (Table 3).  That is, at 80 ppi the error rate is nominally equivalent to that at 
even the higher 100 ppi, but with significantly reduced “scaling+zoning” processing time (from 5.7 
sec/page to 4.1 sec/page).  Compared to the lower resolutions, the 80 ppi option results in both improved 
error rate and equal or improved performance (the one exception to the latter is at 50 ppi, in which the 
combined processing time drops from 4.1 sec to 3.5 sec, but with a doubling in the error rate). 
2. Zoning analysis
 The zoning analysis engine was designed for a per-decision error rate of 0.1% (99.9% 
accuracy on segmentation, classification and bit-depth assignment) with a 75 ppi zoning analysis raster.  If, 
on an average page, there are 10 regions, each of which must be segmented, classified and have its bit-
depth assigned, then there are 30 decisions per page.  At a per-decision error rate of 0.1%, this results in a 
per-page error rate of 100%x(1-(0.999)
30
), or 2.96%.  The per-page error rate using an 80 ppi raster on a 
test set of ~700 pages was 3.1% (Table 3), indicating that a rough estimate for decisions/page was 
approximately 30.  It should be noted that this “rule of thumb” is complicated by the fact that the 
overwhelming majority of pages were grayscale, and so “decisions” on bit depth were generally limited to 
non-text regions.  Since the mean number of regions per page was approximately 10, this implies that the 
per-decision error rate was actually higher than 0.1% in the test set.  In fact, the overall error rate for the 1.2 
x 10
6
page corpus was originally 5.4%, indicating that the sample set of documents chosen was slightly 
more uniform in quality than the overall set.  However, we did not break out the error rates by resolution 
for the overall corpus (since it was generated only once, at 80 ppi, for an obvious reason: more than 2 
processor-years for corpus generation), but have no reasons to suspect any substantive difference for the 
overall corpus from that shown in Table 3. 
Option 
Scale 
Factor 
Scaled 
Resolution (ppi) 
Time for 
Scaling (sec) 
Zoning Page 
Error Rate (pct) 
Zoning 
Time (sec) 
100 
2.2 
2.9 
3.5 
80 
2.1 
3.1 
2.0 
66.7 
2.6 
3.4 
1.8 
57.1 
2.5 
4.0 
1.6 
50 
2.0 
6.2 
1.5 
Table 3.  Possible scale factors, time to perform scaling and its impact on zoning analysis 
performance and accuracy.  The zoning error rate is a by the page (see QA section to see why this is 
justified)—that is, if even one error occurs on a segmentation, classification or bit depth assignment 
decision on a page, it is considered a page error (thus, a 2.96% per page error rate corresponds to a 
0.1% per-decision error rate—see text for discussion).  The scaling and zoning times—and zoning 
page error rates—are based on a sample set of ~700 pages, and so are relatively representative if not 
absolutely representative of the entire 1.2 x 10
6
pages in the digital library (see text for details). 
The zoning analysis classification and bit-depth assignment was limited to the region types described in 
Table 4.  Because text and table regions were treated identically downstream from zoning analysis, we 
combined these regions into a single type (i.e. treated them both as text).  Drawings and graphics were 
sharpened and snapped (similar to the pipeline used to clean up text), but no raster-to-vector conversion—
for example, the creation of SVG [9]—was performed.  Downstream analysis for photo regions consisted 
of blurring (via JPEG compression), and for text and table regions optical character recognition (OCR) was 
performed to generate ASCII/Unicode text from the raster. 
3. OCR engine loading/analysis
 In generating the MIT Press corpus, we integrated the OCR engine 
directly into the DIA workflow for two important reasons: (1) to allow OCR feedback to the zoning 
analysis engine, and (2) to generate overlain text in the PDF files in a single pass.  The former we address 
shortly.  The latter is for convenience.  In a one-pass system, the following workflow is used (Figure 3): 
We independently developed a DIA workflow engine that did not concomitantly generate OCR text—
that is, no OCR engine was integrated—for purposes of performance and workflow comparison [17].  This 
system allows—but does not require—a “two-pass” approach, in which the OCR steps are deferred.  PDF 
and XML files are generated in the first step.  The flowchart for this workflow is shown in Figure 4. 
TIFF File
Read / Scale
PDF Generation
OCR Analysis
Zoning Analysis
XML Generation
OCR Clean-up
Figure 3.  Flowchart of the workflow for one-pass DIA-driven digital library creation.  Notice that 
there are two levels of feedback, one from the “OCR Clean-up” box back to the “OCR Analysis” box, 
and the second from the “OCR Analysis” box back to the “Zoning Analysis” box.  In addition, a 2-
level feedback is possible; that is, “OCR Clean-up” information can be fed directly back to the 
“Zoning Analysis”—for example, hyphenation information can be fed back to the classification 
engine in the zoning analysis system.  We did not utilize this 2-level feedback, but rather allowed the 
“OCR Clean-up” information to affect the “OCR Analysis” directly (and “OCR Analysis” 
information to affect the “Zoning Analysis” directly).  In this matter, 2-level feedback was achieved 
indirectly. 
4. OCR clean-up
 OCR clean-up was straightforward in the MIT Press digital library, because all of the 
texts were written in English (some texts has foreign text in parts, but not in substantial quantity).  We used 
a native-language dictionary to improve OCR as follows: 
-When a word was ostensibly “misspelled”—that is, not in the dictionary—with a common glyph 
substitution, deletion or insertion, but spelled correctly with this error reversed, we changed the word to its 
“correctly” spelled word, and replaced it with this word if more occurrences of this “correctly” spelled 
word were on the same page.  For example, the word “journal” is often incorrectly output by OCR as 
“joumal” (6 letters, the fourth being an “m”).  On pages where “joumal” occurred, we replaced it with 
“journal” (7 letters) if the latter occurred as many or more times on the page as “journal”.  This step was 
done automatically.  Of course, differences in capitalization were noted.  This prevented false positives 
such as replacing technical terms with similarly-spelled but more common words (e.g. Linux for Linus). 
Region Type 
Bit Depth 
Additional Analysis 
Output Resolution (ppi) 
1. Text 
Text pipeline, OCR 
400 
2. Drawing: Line Art 
Drawing pipeline 
400 
3. Graphics (color) 
24 
Drawing pipeline 
400 
4. Table 
Text pipeline, OCR 
400 
5. Photo 
8 / 24 
Photo pipeline 
200 
Table 4.  Region types identified by the zoning analysis engine.  Since “Text” and “Table” were both 
saved as 1-bit, 400 ppi regions, with OCR post-processing, we did not individually tag “Table” 
regions, eliminating one potential (though minor) source of classification error. 
TIFF File
Read / Scale
PDF Generation
OCR Analysis
Zoning Analysis
XML Generation
Figure 4.  Flowchart of the workflow for (potential) two-pass DIA-driven digital library creation.  In 
the first pass, the PDF and/or XML file/s is/are generated.  In the second pass, the OCR analysis is 
performed (and, if necessary, the PDF is generated from the XML or vice versa). 
-When a word was hyphenated at the end of a line of text, we removed the hyphen in the OCR if the 
removal of the hyphen resulted in a dictionary word but the compound word was not found in the 
dictionary.  So, for example, “inter-polate” was cleaned up to “interpolate” but “feeble-minded” was left as 
“feeble-minded” since it is a compound word in the dictionary. 
5. OCR feedback to zoning analysis
 After OCR clean-up took place, OCR results were obtained for 
“borderline” classified regions as follows.  If a region was classified as text, but statistically it was close to 
being classified as a line drawing or else we had no statistical significance on its orientation, we performed 
OCR on the region more than once. 
-Text vs. line drawing.  Based on the thresholded pixels, we estimated how many words should be 
present in a region.  Then we performed OCR on the region.  If the number of OCR engine output words is 
less than 50% of the expected number of dictionary words, we declared the region a line drawing; 
otherwise, we kept the OCR results and declared the region a text region. 
-Orientation.  If it was unclear if the region was landscape or portrait, right-side up or upside-down text, 
we performed OCR sequentially until the same 50% dictionary look-up accuracy was obtained.  If none of 
the OCR attempts reached 50% of expected, we declared the presumed text region to be a line drawing. 
The information on orientation (portrait/landscape and upside down/rightside up) and/or classification 
(text/line drawing) was fed back to the zoning analysis, so that possible region clustering improvement 
could be made (for example, if a region had formerly been classified as “text” and was now classified as 
“line drawing”, the region could be combined with any apposing line drawing regions to simplify the 
segmentation). 
6. PDF generation
.  PDF files were generated using custom-written PDF code because of licensing 
concerns.  Our default compression scheme for text and line drawings was CCITT (now ITU) G4 
compression, although Flate (Huffman encoding and LZ77) compression [25] was also allowed as an 
option.  For photos, JPEG compression with a default quality setting of 95—that is, 95% quality—was 
implemented.  Run-time options are discussed below. 
7. XML generation
 XML files were generated either in place of or in parallel with PDF files.  A simple 
XML schema describing the region boundaries (segmentation), the region classification (region type), the 
region bit depth, and the region Z-order (Z-order is the level, in layers, of each region on a document—the 
background is level 0, overlying text is level 1, etc.) was implemented. 
2.2. Timing 
Timing information presented herein is based on runs of two books (~700 pages) on a Pentium-III 
laptop with 256 MB RAM and a clock speed of 1.13 GHz.  The OCR engine loading and the actual 
character recognition process were the most prohibitive document image analyses performed in the project.  
The TIFF reading and scaling took 2-3 seconds, zoning analysis approximately 2 seconds, PDF generation 
2-3 seconds, XML generation 1-2 seconds, OCR engine loading and analysis 20-30 seconds, and OCR 
clean-up and feedback 1-2 seconds.  The mean page thus took 28-42 seconds to process.  When the entire 
system for processing is accounted for [6], including page-based and book-based quality assurance, loading 
tapes and distributing files to a multiple-computer system, the overall processing time climbs to 
approximately one minute per page.  This is 2.3 processor-years. 
2.3. Run-time options 
Because customer needs in quality, file size, and the ability to extract further information from the files 
will vary, we built many options into the DIA engine.  Some of the more salient options are described here. 
1. Input Directory.  Where the files to be analyzed are located 
2. Output Directory.  Where the files (PDF, XML) that are created are to be stored. 
3. Output region resolution.  The default is 400 ppi for all regions to allow maximum re-purposability, 
although it can be specified to be lower (e.g. 200 ppi) to reduce file size. 
4. Skew detection and correction.  Skew of the files is automatically computed as part of the zoning 
analysis.  If needed, the skew can be corrected. 
5. Auto-exposure.  If the scanned files are under-exposed, they can be corrected automatically (auto-
exposure). 
6. Bit depth for text (default 1) can be set to 8. 
7. Bit depth for drawings (default 8) can be set to 1, 8, or 24. 
8. Bit depth for photos (default 8) can be set to 1, 8 or 24. 
9. JPEG quality can be set anywhere in the range of 0-100%.  JPEG compression is used for all 8- and 24-
bit regions in the output PDF files.  The default setting for “quality” is 95%.  This can be used to 
automatically make the file sizes match a pre-imposed restriction. 
10. The users can choose to generate PDF and/or XML file output per their needs. 
11. The user can choose between CCITT/G4 and Flate compression [25] for the 1-bit regions. 
12. The user can force the zoning regions to be all rectangular (termed Manhattan layout, this is useful to 
simplify the zoning results, and in QA to give it a second chance to passed automatic QA).  This is the “-
rects” option shown in Figure 5. 
13. The user can also force the zoning region to be a single black and white region (which is appropriate, 
for example, if the document is all text). This is the “-1bw” option shown in Figure 5. 
14. The user can force the zoning regions to be all rectangular and to be either 1-bit (binary text) or 8-bit 
gray (this works well for true Manhattan layouts with only text and 8-bit gray regions).  This is the “-
rectgray” option in Figure 5. 
15. The user can, additionally, force the zoning region to be a single 8-bit (gray) rectangle (this works well 
for true Manhattan layouts with no text regions).  This is the “-1gray” option in Figure 5. 
16. Finally, if the default zoning analysis and the options in (12-15) above do not pass automated QA, the 
user can use the ground truth schema (XML) as input for the zoning analysis (this allows 100% accurate 
zoning analysis to be specified using the separate Ground Truthing Engine application, also described 
below).  This is the “-gt” option in Figure 5.  We discuss the options 12-16 in more detail in the next 
section. 
3  Quality Assurance 
Automatic quality control during document image capture is an integral part of the MIT Press digital 
library system.  We discuss automated quality assurance (QA) for code that we are responsible for (zoning 
analysis); we discuss improving the output of commercial-off-the-shelf (COTS) software such as OCR in 
terms of meta-algorithmics in the next section.  QA is performed on a per-page basis.  This is done for 
several reasons, the most important of which are (1) the distribution of tasks among processors hooked 
together for the project is done on a per-page basis, (2) the QA metric for zoning analysis (Figure 5) is 
based on comparing a single output page to its original TIFF page, and (3) the zoning on a per-page basis is 
often quite simple for most pages, allowing us to readily “rank” QA candidates for zoning. 
As shown in Figure 5, our zoning analysis default is to call the API method AnalysisNew() that 
performs default segmentation and classification. This is followed by the method 
AnalysisAlterRegionPresentationAfterZoning() that enforces a specific region manager on the output of 
AnalysisNew().  For our purposes, we chose to have non-overlapping regions and to treat tables identically 
to text in this step.  As noted in Table 3, 96.9% of the ~700 pages in our sample set passed subsequent QA 
without error after this step.  Thus, in the first “decision diamond” shown in Figure 5, the question “Passes 
AutoQA?” is 96.9% YES, 3.1% NO. 
For the 3.1% of documents that failed “AutoQA” after the default zoning analysis, the next “zoning 
analysis candidate” was used.  We based the order of the next four engines on their conditional 
probabilities.  Given a page has failed the original zoning analysis, which (if any) of the “-rects”, “-1bw”, 
“-rectgray” and “-1gray” options is most likely to correctly zone the page? 
This ordering is important, because after the original zoning analysis engine has failed, the remaining 
zoning analysis candidates are simply guesswork.  Moreover, each subsequent analysis attempt requires 
that a PDF output file be generated and compared to the original TIFF file using a regenerated TIFF file.  
This is a time-consuming process.  However, since each subsequent attempt reduces the error rate 
substantially, by the time the “-1gray” option has been exhausted, the error rate has dropped from 3.1% to 
0.8%. 
A ground-truthing engine [10,11] is used as the final step in the QA of our digital library creation 
system.  When automatic QA cannot be passed, a human operator needs to examine the document and 
specify the correct page layout.  In creating the MIT Press digital library, as noted, 99.2% of all pages 
passed automatic QA after the completion of the method AnalysisForceGrayRectangularPageRegion() 
shown in Figure 5.  The automatic QA assessment is performed using a verifier in which the PDF output 
file of the page gets regenerated as a TIFF image, which is then compared to the original scan [6].  Large 
deviation between the two images implies an error in page processing. 
Documents you may be interested
Documents you may be interested