Report on the comparison of Tesseract and 
ABBYY FineReader OCR engines 
Marcin Heliński, Miłosz Kmieciak, Tomasz Parkoła
Poznań Supercomputing and Networking Center, Poland
Table of contents 
1. Introduction ............................................................................................................................ 2
2. Training process .................................................................................................................... 2
2.1 Tesseract training process ................................................................................................ 3
2.2 FineReader training process ............................................................................................. 8
3. Comparison of Tesseract and FineReader ............................................................................10
3.1 Evaluation scenario .........................................................................................................10
3.1.2 Evaluation criteria ......................................................................................................12
3.2. OCR recognition accuracy results ...................................................................................13
3.3 Comparison of Tesseract and FineReader recognition accuracy .....................................20
4 Conclusions ...........................................................................................................................23
IMPACT is supported by the European Community under the FP7 ICT Work Programme. The project is 
coordinated by the National Library of the Netherlands. 
Pdf to tiff c# open source - application control cloud:C# PDF Convert to Tiff SDK: Convert PDF to tiff images in C#.net, ASP.NET MVC, Ajax, WinForms, WPF
Online C# Tutorial for How to Convert PDF File to Tiff Image File
www.rasteredge.com
Pdf to tiff c# open source - application control cloud:VB.NET PDF Convert to Tiff SDK: Convert PDF to tiff images in vb.net, ASP.NET MVC, Ajax, WinForms, WPF
Free VB.NET Guide to Render and Convert PDF Document to TIFF
www.rasteredge.com
1. Introduction 
The aim of this report is to compare OCR accuracy of two well known OCR engines: Tesseract 
3.0.1 and FineReader10 Corporate Edition. The comparison is based on Polish historical printed 
documents and ground-truth produced within the scope of the IMPACT project (available at 
http://dl.psnc.pl/activities/projekty/impact/results/). As a rule defined by the IMPACT project the 
document is assumed to be historical if it was printed before 1850. Tesseract and FineReader 
have been selected because both represent high-level solution coming from open-source and 
commercial community and both were the  subject of research works in the  scope of the 
IMPACT project. The idea of the works described in this report was to verify in practice how 
these two tools can be fine-tuned by the end user in order to improve recognition rate of the 
historical printed text as well as compare the results of OCR accuracy after fine-tuning of both 
tools.  
In order to efficiently train Tesseract engine it was needed to enhance part of IMPACT ground-
truth data with regions on a character level. Such a detailed ground-truth data could be then 
used to prepare appropriate training data for Tesseract engine. Training of FineReader was 
done using the built-in mechanism of this OCR engine and did require ground-truth data on a 
region level. For OCR accuracy rate calculation IMPACT ground-truth data on a region level 
was used. The tools used to calculate OCR accuracy were provided by the IMPACT project 
partner 
the National Centre of Scientific Research "DEMOKRITOS". 
There were several types of experiments performed in the context of OCR training, including 
document level training, whole dataset training and incremental OCR training. All of these 
experiments were done to provide an overall view of the OCR results that can be expected from 
particular OCR engines after particular training efforts. The conclusions include the observations 
related to the recognition accuracy on character and word level in the context of characteristics 
of the pages being OCRed. 
The second chapter describes the training process applied to Tesseract and FineReader with 
details and rationale related to particular training approach. The third chapter includes main part 
of this report and is focused on the:  
Evaluation scenario and criteria that has been used in order to assess the recognition 
quality and further compare both OCR engines. 
Observations related to OCR recognition accuracy for particular documents processed 
with the use of certain OCR engine. 
Analysis of the recognition accuracy of the Tesseract and FineReader engines for the 
purpose of comparison. 
The last chapter is a summary with conclusions related to the comparison of FineReader and 
Tesseract OCR engines, with the focus on the problems and challenges that certain OCR 
engine should face and improve. 
2. Training process  
In case of Tesseract automated approach to the training process has been selected. The 
training of the Tesseract covered all the necessary steps according to the guidelines of the 
application control cloud:C# PDF Text Extract Library: extract text content from PDF file in
using RasterEdge.XDoc.PDF; Please have a quick test by using the following C# example code for text extraction from PDF page. // Open a document.
www.rasteredge.com
application control cloud:C# PDF File Merge Library: Merge, append PDF files in C#.net, ASP.
Free online C#.NET source code for combining multiple PDF pages together in .NET framework. Combine scanned images to PDF, such as tiff, jpg, png, gif, bmp
www.rasteredge.com
documentation. As a result a complete set of trained data for Tesseract was obtained and 
prepared  for  download  for  all  interested  parties.  The  trained  data  is  available  at 
http://dl.psnc.pl/activities/projekty/impact/results/. The trained data is available both for gothic 
and aniqua documents. It is important to note that these resources are constrained to the data 
selected  during  the IMPACT project,  nevertheless  they can  be  used  for  further  analysis, 
research  and improvements. 
In case of FineReader the manual approach was selected. It means that the training process 
was performed using the built-in mechanism in the FineReader Corporate Edition. The training 
was prepared and performed according to the documentation and recommendations of the 
ABBYY company representatives (IMPACT project partner), who suggested to evaluate this 
feature of FineReader only on a document level, as this would guarantee good FineReader 
results. As also stated by the ABBYY, general training, e.g. for whole gothic or antiqua dataset, 
requires ABBYY paid involvement, which means internal training of the FineReader. As this paid 
service of training was not in the scope of the pilot work, this kind of results was not obtained for 
the FineReader.  Nevertheless, in case of gothic  text ABBYY provided estimated price for 
training  FineReader  on  Polish  gothic  documents  that  are the  subject  of this  report. The 
estimated rate could be then compared with efforts needed by PSNC staff to train Tesseract on 
the same set of gothic documents.  
2.1. Tesseract training process 
Tesseract OCR 3.0.1 can be fully trained in order to support non standard languages: character 
sets and glyphs. The training process is described in the training manual
1
and can be easily 
scripted to  process  training  automatically  (refer to train.sh  script for detailed information). 
However, training data needs to be gathered and stored in a strictly specified form. In order to 
use the IMPACT dataset for Polish language containing set of historical images and ground-
truthed corresponding full text content, it requires transformation. The transformation steps are 
described in the subsequent paragraphs. 
Training data for Tesseract includes examples of scanned documents along with the full text 
content for these documents. As stated in the documentation, the training data should be as 
much  natural  as  possible  in  the  context  of  page  layout,  words  spacing  and  characters 
combinations commonly used in the language. On the other 
hand, given images shouldn’t 
contain too much noise (e.g. bad quality of scanned images) in order to provide valuable 
training data. 
Full text content has to be stored in Tesseracts format called box file. It is made of character 
unicodes and boxes, that is coordinates of rectangles bounding all characters found in the 
scanned page. As a given page should base on a single font, it may be difficult to provide real 
historical documents as different font types are often used within the same page (e.g. italics). 
However, Tesseract allows characters to have a font type modifier attached, and therefore to 
distinguish glyphs of a different font type, but referring to the same character. This approach 
1
http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3 
application control cloud:C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
is a widely-used form of file that allows users to open & read With the purpose of helping C#.NET developers manipulate and edit PDF document file
www.rasteredge.com
application control cloud:VB.NET PDF Annotate Library: Draw, edit PDF annotation, markups in
Decode source PDF document file into an in-memory object, namely 2.pdf" Dim outputFilePath As String = Program.RootPath + "\\" Annot_8.pdf" ' open a PDF file
www.rasteredge.com
was used in the antiqua training process, where 
$
character was added to indicate italic font 
type in the training data. In case of the training process for gothic texts, antiqua font was 
excluded from the training data because of two reasons. First of all the ratio between number of 
antiqua and  gothic glyphs is low. Secondly, we wanted to test a vanila version of Tesseract with 
only one font trained. 
In case of the IMPACT dataset, each page is represented by files that follow a particular naming 
convention. Files related to a single page are identified by a unique number, with a suffix 
depending on the file’s type. File names suffixed by ‘.tif’ contain images of scanned pages 
stored in a lossless TIF format.  Full text content is stored in files complying with the PAGE XML 
format
2
(denoted by ‘.xml’ suffix). Finally
, documents from the dataset may contain both italic 
and non-italic or fraktur and non-fraktur font shapes (glyphs) in the same sentence, dataset is 
extended by further description. Each page may have a third corresponding file,  a UTF-8 
encoded list of identifiers of text regions that were selected as non-fraktur or italic words. These 
text files have ‘.txt’ suffix.
In the first step glyph’s repository needs to be created, which contains information on glyph 
shapes found in a particular page from the dataset. Information includes bounding coordinates 
of a glyph, unicode character mapping, binarisation threshold as well as font parameters. All this 
allows to generate a denoised form of the original page, e.g. with simplified page layout  or 
excluded font types. To generate a glyph repository one needs to use a Cutter tool. 
The following options are required:     --image     --xml  
Usage: pl.psnc.synat.a12.aletheia.Cutter [options] 
Args:     directory name for output files 
Options: 
--font            mark generated glyphs as a {gothic, italic} font 
--help            print this help 
*     --image           file name of a image input 
--only-read-xml   reads only xml file, does not generate anything 
--tabu            file name of a text file containing list of noise 
word's ids 
--tabu-types      list of TextRegion types to omit during processing 
Default: [] 
*     --xml             file name of a page xml input
This tool requires two files as an input: a page image and a ground truth XML file. In case of the 
IMPACT dataset, images should be transformed to PNG format prior to repository generation 
process. This can be done e.g. by using ImageMagick convert
3
tool: 
convert 003287.tif 003287.png 
Output repository should be stored in a separate directory, hence its name is a mandatory 
parameter  of  the  application.  The 
--font
option  allows  to  add  font  type  to  characters 
2
http://www.primaresearch.org/papers/ICPR2010_Pletschacher_PAGE.pdf 
3
ImageMagic identify tool described at 
http://www.imagemagick.org/script/convert.php 
application control cloud:C# Create PDF from OpenOffice to convert odt, odp files to PDF in
Online source code for C#.NET class. to Use C#.NET Demo Code to Convert ODP to PDF in C#.NET Application. Description: Convert to PDF/TIFF and save it on the disk
www.rasteredge.com
application control cloud:C# PDF: PDF Document Viewer & Reader SDK for Windows Forms
DocumentViewer.dll"; Then, you will see .NET WinViewer DLL Control in VS Toolbox. Open a PDF Document in C#.NET WinForms Viewer. After adding
www.rasteredge.com
processed by the application, excluding characters from word regions listed in 
--tabu
file. The 
latest are marked with ‘noise’ font type by default. In order to filter out text regions basing on 
their type, a list of tabu types can be passed by using the 
--tabu-types
parameter. It is used 
for simplifying layout of pages generated in the second step. Available region types are: 
paragraph, heading, caption, header, footer, page-number, drop-capital, credit, 
floating, signature-mark, catch-word, marginalia, footnote, footnote-continued, TOC-
entry 
For experiments described in this report only paragraph and heading region types were included 
as their font size is comparable and reading order is well defined. The latest parameter 
--
only-read-xml
enables dry run of the application, which allows to check if provided ground 
truth file contains any errors, e.g. referring to wrong characters encoding. Application can be run 
as in the following example: 
java pl.psnc.synat.a12.aletheia.Cutter --image 003287.png --xml 
003287.xml --tabu 003287.txt --tabu-types caption --tabu-types header 
--font gothic 003287 
which results in a glyphs repository in output directory named 003287/. The cutting process is 
as follows. Process text regions, unless a region’s type was indicated as a tabu type. For each 
text region denoting words in a given ground truth XML file that does not appear on the tabu list, 
glyphs are processed. Each glyph is cropped from the original image basing on its bounding 
coordinates. For each cropped subimage a binarization threshold is sampled basing on the Min 
fuzziness approach implemented in the JAI
4
library. Eventually, binarised glyph is stored in a 
PNG  file  along  with  its  unique  identifier,  coordinates  within  the  original  image,  applied 
binarisation threshold, corresponding ground truthed code point and font attributes. 
This tool was applied to pages from the IMPACT dataset ground truthed at the glyph level, that 
represent gothic and antiqua Polish historical texts. Processing summary is presented in the 
following table: 
Table 1 Processing summary of the Polish historical texts 
Dataset 
Number of glyph repositories 
Fraktur/Gothic 
287 
Antiqua 
186 
In the next step, glyphs repository can be used for generating denoised versions of the original 
images. As repository contains information on font types, one can filter out only required fonts, 
excluding e.g. words written as italic antiqua from the fraktur (gothic) texts. Moreover, as in the 
first step tabu regions could be excluded from the repository, a layout of the generated page can 
4
Java Adcanced Imaging API 
http://java.sun.com/javase/technologies/desktop/media/jai/ 
application control cloud:C# Word - MailMerge Processing in C#.NET
In C# class programming, you can use XML file which contains data source, and execute String docFilePath = @""; String xmlFilePath = @""; Open the document
www.rasteredge.com
application control cloud:VB.NET PDF File Split Library: Split, seperate PDF into multiple
Separate source PDF document file by defined page range in VB.NET class application. Divide PDF file into multiple files by outputting PDF file size.
www.rasteredge.com
be simpler than in the original image. Page can be generated by Generator CLI (Command Line 
Interface) application: 
The following options are required: -w, --width -h, --height  
Usage: pl.psnc.synat.a12.generator.CLI [options] 
Args: <box_dir_path> [ <image_filename> ] 
Options: 
--baselines      generate and output baselines offsets to given filename 
-b, --box            generate and output ".box" data to given filename 
--em-ratio       set space to em size ratio, used for spaces detection 
--font-type      output font type in output box file 
* -h, --height         set height of generated output image 
--no-image       do not generate output image 
--overlap        allows letter bounding boxes to overlap (default no 
overlaping) 
Default: false 
--skip-gothic    skip gothic letters in output 
--skip-italics   skip italic letters in output 
--skip-noise     skip noised letters in output 
-t, --text           generate and output text to stdio 
-v, --verbose        turn on verbose mode 
* -w, --width          set width of generated output image 
Application requires four arguments: width and height of the generated image, path to glyphs 
repository and output image filename. In order to generate cleaned form of the original page, 
the first two arguments should match dimensions of the original image. These can be retrieved 
e.g. by a ImageMagick identify command
5
identify -format "-w %w -h %h" 003287.png 
As font type filtering is required, one can use one of the 
--skip-*
options. It is possible to 
generate box files related to cleaned  images by  passing the 
--box
parameter  along with 
requested file name, whereas the 
--font-type
switch instructs application to attach encoded 
font type to characters stored in the box file. Eventually, exemplary application call: 
java pl.psnc.synat.a12.generator.CLI -w 560 -h 1203 --box 003287-
clean.box --font-type 003287/ 003287-clean.png 
reads glyphs repository from 
003287 
directory and generates both page image 
003287.png
(with given dimension 560x1203) and corresponding box file 
003287.box
. The latest contains 
font type marks e.g. for italic glyphs.  
The generated image is made of binarised glyphs stored in a given glyphs repository. As 
coordinates within the original image are given for each glyph, the original glyph location can be 
easily  restored,  preserving  letters, words  and  line  spacing. Moreover,  as  glyph  repository 
contains binarised images, generated images contain much less noise than the original ones. 
5
ImageMagic identify tool described at 
http://www.imagemagick.org/script/identify.php 
application control cloud:C# Create PDF from Tiff Library to convert tif images to PDF in C#
Selection of turning tiff into searchable PDF or scanned PDF. Online demo allows converting tiff to PDF online. C# source codes are provided to use in .NET class
www.rasteredge.com
Please note, that this approach represents local binarisation method and should be more 
effective than methods binarising whole image at once. 
Finally, generated data can be provided for the Tesseract training process. This process can be  
automated with the following bash script
6
train.sh: 
# Path to Tesseract instalation 
TESS_HOME=tesseract-3.01 
FONTNAME=antiqua 
# paths with tesseract's binaries and shared data  
TESS_BIN=$TESS_HOME/bin 
TESS_SHARE=$TESS_HOME/share/tessdata 
# document specific settings 
LANG=pl 
############################################### 
NAME=$LANG.$FONTNAME.exp 
TIFNAME=.png 
echo "combined 0 0 0 0 1" >font_properties && 
$TESS_BIN/unicharset_extractor *.box && 
for x in `cat files.txt` 
do 
echo "tesseract training $x$TIFNAME" 
$TESS_BIN/tesseract $x$TIFNAME $NAME$x nobatch box.train.stderr 
done 
cat *.tr >combined.tr 
$TESS_BIN/mftraining -F font_properties -U unicharset -O $FONTNAME.unicharset 
combined.tr &&                
$TESS_BIN/cntraining combined.tr || exit                                                                       
mv pffmtable $FONTNAME.pffmtable                                                                                       
mv normproto $FONTNAME.normproto                                                                                       
mv inttemp $FONTNAME.inttemp 
$TESS_BIN/combine_tessdata $FONTNAME.  
# && cp -v $FONTNAME.traineddata $TESS_SHARE/$FONTNAME.traineddata 
The transformation process for an exemplary page with id 003287 is summarised in the table 
below: 
Table 2 Transformation process for an examplary page with id 003287 
Transformation step 
Input 
Output 
convert 
003287.tif 
003287.png 
pl.psnc.synat.a12.aletheia.Cutter 
003287.png 
003287.xml 
003287.txt 
003287/ 
pl.psnc.synat.a12.generator.CLI 
003287/ 
003287-clean.png 
003287-clean.box 
6
This script was created for Tesseract 3.01 release.
train.sh 
003287-clean.png 
003287-clean.box 
clean.traineddata 
2.2 FineReader training process 
FineReader 10 Corporate Edition allows training text recognition manually only on the document 
level. Only characters included in the alphabet of the recognition language can be used to train 
FineReader. Trained characters are stored in the user pattern which together with recognition 
language and other options can be saved into the file for later use. However, pattern can only 
be used for documents that have the same font, font size, and resolution as the document used 
to create the pattern. 
Considering the above rules and limitations, the process of training FineReader began with 
creating  OCR  language.  That  language  was  based  on  the  Polish  language  available  in 
FineReader and was extended with the characters used in the training dataset. These contained 
mainly characters that cannot be entered from the keyboard, especially ligatures, old characters 
such as long s, and accented characters such as a with acute above. Two separate languages 
were created to support gothic and antiqua documents. 
Once the recognition language was ready the pattern training could be started. The training 
process was performed on a cleaned black and white images. Training results were used for 
testing two data sets - cleaned black and white images and real scans without any changes. 
For each training set the user pattern was created before training the first page had started. The 
user pattern name consisted of the associated training set name and the number of trained 
pages. 
Figure 1 Pattern editor of the FineReader 10 CE OCR engine 
While training, FineReader shows the unrecognized character bounded with the green frame. 
When the boundaries were detected incorrectly the frame size was manually adjusted to the 
character being recognized. If necessary, the character was entered from the keyboard or 
selected from the recognition language character set. 
Figure 2 Training process of the FineReader 10 CE OCR engine 
If the quality of the character being recognized was poor it was skipped on purpose. The reason 
for that was not to perturb the pattern with images showing part of a character similar to the 
other real character. 
After training each page the pattern and the settings were saved to a file. Next the user pattern 
was renamed to include the following page. The above actions had been performed until all 
pages in the training set were trained. 
The training approach used in the comparison is quite narrow and has several limitations 
described in the beginning of this section. Additionally it is very time-consuming. Unfortunately 
training FineReader on a broader scale requires purchasing an expensive service that exceeds 
the funds and scope of this pilot work. 
During training several problems were encountered. The first problem was associated with the 
frame bounding the character being recognized. Sometimes it happened that the frame was not 
placed in the beginning of the character. The only way to adjust the frame size was to make it 
wider but the position of the left edge could not be changed. In that case the part of the 
character was skipped. 
Another problem was with italic characters. Sometimes the character (especially 
“ſ” –
long s) 
overlapped the character next to it. In that case the right edge of the bounding frame was placed 
in a way to avoid overlapping. This meant that only part of the character was within the frame 
but since all other cases were similar the recognized character could be stored in the pattern. 
3. Comparison of Tesseract and FineReader 
3.1 Evaluation scenario 
In order to compare Tesseract and FineReader OCR engines, the evaluation scenario is based 
on the hold-out test and train approach, where dataset is randomly split into two disjoint 
subsets. First one is used only for the training purpose in order to create customised OCR 
engine and is referred to as training set. Later on, a customised OCR engine is applied to the 
second subset, a testing set. This results in full text content, of which quality is verified with the 
ground truth. The initial set of pages was divided into separate datasets, each referring to a 
single document, therefore enabling training process of FineReader (please refer to Section 2.2 
for more details). Moreover, in case of Tesseract it was also possible to perform evaluation on a 
broader set of pages from several documents, hence additional ‘all’ dataset was created as well. 
The two following tables present number of pages used in datasets for training and testing for 
fraktur and antiqua fonts respectively. 
Table 3 Number of pages used in datasets for training and testing for fraktur based documents. 
Dataset name 
Number of training pages 
Number of test pages 
test-14 
14 
test-16 
17 
test-19 
14 
test-21 
15 
test-22 
41 
Documents you may be interested
Documents you may be interested