If identifying text structure in PDF documents is so difficult, how do PDF readers do it so well?
Question: I have been trying to write a simple console application or PowerShell script
to extract the text from a large number of PDF documents. There are several
libraries and CLI tools that offer to do this, but it turns out that none are
able to reliably identify document structure. In particular I am concerned
with the recognition of text columns. Even the very expensive PDFLib TET tool
frequently jumbles the content of two adjacent columns of text.

It is frequently noted that the PDF format does not have any concept of
columns, or even words. Several answers to similar questions on SO mention
this. The problem is so great that it even warrants academic research. [This
journal article](http://aclweb.org/anthology//W/W12/W12-3211.pdf) notes:

    
    
    All data objects in a PDF file are represented in
    a visually-oriented way, as a sequence of operators
    which...generally do not convey information about higher
    level text units such as tokens, lines, or columns—
    information about boundaries between such units is
    only available implicitly through whitespace
    

Hence, all extraction tools I have tried (iTextSharp, PDFLib TET, and Python
PDFMiner) have failed to recognize text column boundaries. Of these tools,
PDFLib TET performs best.

However, SumatraPDF, the very lightweight and open source PDF Reader, and many
others like it can identify columns and text areas perfectly. If I open a
document in one of these applications, select all the text on a page (or even
the entire document with CTRL+A) copy and paste it into a text file, the text
is rendered in the correct order almost flawlessly. It occasionally mixes the
footer and header text into one of the columns.

So my question is, how can these applications do what is seemingly so
difficult (even for the expensive tools like PDFLib)?

EDIT 31 March 2014: For what it's worth I have found that PDFBox is much
better at text extraction than iTextSharp (notwithstanding a bespoke Strategy
implementation) and PDFLib TET is slightly better than PDFBox, but it's quite
expensive. Python PDFMiner is hopeless. The best results I have seen come from
Google. One can upload PDFs (2GB at a time) to Google Drive and then download
them as text. This is what I am doing. I have written a small utility that
splits my PDFs into 10 page files (Google will only convert the first 10
pages) and then stitches them back together once downloaded.

EDIT 7 April 2014. Cancel my last. The best extraction is achieved by MS Word.
And this can be automated in Acrobat Pro (Tools > Action Wizard > Create New
Action). Word to text can be automated using the .NET OpenXml library. [Here
is a
class](http://code.msdn.microsoft.com/office/CSOpenXmlGetPlainText-554918c3/sourcecode?fileId=71592&pathId=851860130)
that will do the extraction (docx to txt) very neatly. My initial testing
finds that the MS Word conversion is considerably more accurate with regard to
document structure, but this is not so important once converted to plain text.


Answer: I once wrote an algorithm that did exactly what you mentioned for a PDF editor
product that is still the number one PDF editor used today. There are a couple
of reasons for what you mention (I think) but the important one is focus.

You are correct that PDF (usually) doesn't contain any structure information.
PDF is interested in the visual representation of a page, not necessarily in
what the page "means". This means in its purest form it doesn't need
information about lines, paragraphs, columns or anything like that. Actually,
it doesn't even need information about the text itself and there are plenty of
PDF files where you can't even copy and paste the text without ending up with
gibberish.

So if you want to be able to extract formatted text, you have to indeed look
at all of the pieces of text on the page, perhaps taking some of the line-art
information into account as well, and you have to piece them back together.
Usually that happens by writing an engine that looks at white-space and then
decides first what are lines, what are paragraphs and so on. Tables are
notoriously difficult for example because they are so diverse.

Alternative strategies could be to:

  * Look at some of the structure information that is available in _some_ PDF files. Some PDF/A files and all PDF/UA files (PDF for archival and PDF for Universal Accessibility) must have structure information that can very well be used to retrieve structure. Other PDF files may have that information as well.
  * Look at the creator of the PDF document and have specific algorithms to handle those PDFs well. If you know you're only interested in Word or if you know that 99% of the PDFs you will ever handle will come out of Word 2011, it might be worth using that knowledge.

So why are some products better at this than others? Focus I guess. The PDF
specification is very broad, and some tools focus more on lower-level PDF
tasks, some more on higher-level PDF tasks. Some are oriented towards "office"
use - some towards "graphic arts" use. Depending on your focus you may decide
that a certain feature is worth a lot of attention or not.

Additionally, and that may seem like a lousy answer, but I believe it's
actually true, this is an algorithmically difficult problem and it takes only
one genius developer to implement an algorithm that is much better than the
average product on the market. It's one of those areas where - if you are
clever and you have enough focus to put some of your attention on it, and
especially if you have a good idea what the target market is you are writing
this for - you'll get it right, while everybody else will get it mediocre.

(And no, I didn't get it right back then when I was writing that code - we
never had enough focus to follow-through and make something that was really
good)

