Some time ago, I had to do a little research on my work. Its essence was to find the best pdf parser implemented in java.

A bit about the project. It implements a system for sending internal messages to which files can be attached. There is also a search that should be carried out on the contents of the attachments. Most of these attachments are pdfs.
Actually, the mechanism’s operation is quite simple: when sending a message, attachment data is parsed and an index is parsed on it.

For a long time, documents were parsed using the PDFBOX library, the work of which did not cause anyone joy: for a long time and with failures.
As a result, 4 libraries were selected, the comparison of which I took up: PDFBOX, JPod, iText and Acrobat.

The acrobat was ruled out almost immediately, as It turned out that this library has not been supported for several years, but statistics on it remained, so I will publish it too.
We had to compare libraries according to two criteria - the speed of work and the quality of the results.
I’ll warn you right away: the libraries were tested on internal documents, and they fall under a certain security system. So I can’t even indicate the names. I can only say one thing - the content of the files was the most diverse: text, image tables, scans, etc. File sizes also vary quite a bit, so objective estimates can be expected.

Estimated time:

file size	Pdfbox	Acrobat	Jpod	iText
74.1 KB	00: 02.591	00: 03.155	00: 01.683	00: 00.963
257.5 KB	00: 01.680	00: 03.191	00: 00.116	00: 00.78
1,6 MB	00: 05.805	00: 02.884	00: 02.532	00: 02.79
28.1 MB	E	01: 10.983	00: 43.815	E
13.6 MB	00: 05.218	00: 04.331	00: 00.599	00: 00.77
1.9 MB	00: 02.782	00: 14.506	00: 00.608	00: 00.707
1,6 MB	00: 06.182	00: 02.98	00: 00.906	00: 02.413
8.9 MB	00: 05.98	00: 03.894	00: 00.680	00: 00.647
2,4 MB	00: 14.15	00: 07.893	00: 02.826	E
604.7 KB	00: 03.342	00: 04.721	00: 00.551	00: 01.222
100.6 KB	00: 01.819	00: 04.212	00: 00.84	00: 00.456
1,6 MB	00: 05.633	00: 03.99	00: 00.883	00: 02.18
10.3 MB	00: 22.311	00: 22.145	00: 27.663	E
1.9 MB	00: 06.943	00: 14.736	00: 01.200	E
2.1 MB	00: 02.573	E	00: 00.498	00: 00.475
111.0 KB	00: 01.956	00: 02.846	00: 00.705	00: 00.300
814.3 KB	00: 02.552	00: 04.221	00: 00.306	00: 00.900
2.0 MB	00: 06.319	00: 07.128	00: 01.821	00: 02.796
338.7 KB	00: 01.950	00: 03.684	00: 00.79	00: 00.415
12.9 MB	00: 15.932	00: 13.628	00: 04.989	E
7.3 MB	E	00: 17.275	00: 16.377	E
97.2 MB	00: 27.291	00: 01.994	00: 05.739	E
5.2 MB	00: 07.773	00: 11.108	00: 01.964	E
Total:
Best	0	2	14	7
Middle	12	7	8	8
Worst (including errors)	eleven	14	1	8
Errors	2	1	0	8

The worst and best times are highlighted in red and green, respectively. The letter “E” indicates the state of permanent collapse that has overtaken the process due to buffer overflows or any other errors.
In comparison of time, the objective winner was JPod. Pleased with the lack of parsing errors.

Quality control:

Quality assessment was quite subjective and was divided into only 3 categories: Best, Middle and Worst. There is also an Empty score, which was set if during the parsing process a collapse occurred or the parser simply did not find text inside the document.
The similarity of the received text with the original was assessed, but not very critical, because the text was needed for the index, not for output.

file size	Pdfbox	Acrobat	Jpod	iText
74.1 KB	Best	Middle	Best	Best
257.5 KB	Best	Middle	Best	Empty
1,6 MB	Best	Empty	Empty	Worst
28.1 MB	Empty	Middle	Best	Empty
13.6 MB	Empty	Empty	Empty	Empty
1.9 MB	Best	Middle	Worst	Middle
1,6 MB	Best	Empty	Worst	Worst
8.9 MB	Best	Middle	Middle	Best
2,4 MB	Best	Middle	Worst	Empty
604.7 KB	Best	Middle	Middle	Middle
100.6 KB	Best	Middle	Best	Empty
1,6 MB	Best	Empty	Worst	Worst
10.3 MB	Best	Best	Best	Empty
1.9 MB	Best	Best	Best	Empty
2.1 MB	Best	Best	Best	Empty
111.0 KB	Best	Best	Best	Best
814.3 KB	Best	Worst	Best	Best
2.0 MB	Best	Middle	Best	Best
338.7 KB	Middle	Middle	Best	Empty
12.9 MB	Best	Best	Best	Empty
7.3 MB	Empty	Best	Best	Empty
97.2 MB	Best	Best	Middle	Empty
5.2 MB	Best	Best	Best	Empty
Total:
Best	19	8	14	5
Middle	1	10	3	2
Worst (including empty)	3	5	6	16
Empty	3	4	2	thirteen

Characteristic features of parsing:
Acrobat very often parses text on one line. Gaps between words and sentences remain, therefore, in principle, this is not critical for indexing.
iText does not understand non-English characters. The tests used documents in English, German and French. Therefore, all their umlauts went into the forest. They didn’t even just go to the forest - instead of such characters, I received questions. Perhaps this is somewhere tuned, but the rest understood such symbols without dancing with a tambourine.
PDFBOX on quality of complaints did not cause.
JPod - everything is ok too. Except for one feature that made him mess around for quite some time. In some cases, a document is parsed in whole or in part by one letter per line - for an index such parsing is useless.

As a result, JPod was declared the winner, despite its peculiarity to parse letter by line.
I had to deal with this.

Part two. Inside the JPod.

Picking the source code for JPod took a lot of time. Letters, project forum. As a result, it was found that such parser behavior is caused by the orientation of the document pages. Portrait orientation is fine, but landscape is not. Attempts to pick out the parameters did not work. The class properties responsible for page orientation were useless.
In general, at one point, I decided to simply remove all fonts from the classes. Anyway, they are not needed for indexing text. It helped because blocks of text were not calculated correctly, and this was caused by fonts.
Here I would stop, but Egiptyanin insisted that it was nevertheless necessary to reach the end. Then I almost did not participate.
A solution was found, and in this form it is used: the matrix of affine transformations was redefined. Instead of a dynamic matrix, a static one was set. The CSPlainTextExtractor class was used instead of the CSTextExtractor. The new class looks like this: Of course, this is not a panacea and very rarely the parser does not add hyphens to the necessary places, but this is not important for indexing. Actually, that's all. Thank you for your attention =) PS This is my first more or less serious article, I hope for objective criticism. Upd Particularly attentive readers found in the tables of inconsistencies - fixed.

public class CSPlainTextExtractor extends CSTextExtractor {
public void textSetTransform(float a, float b, float c, float d, float e, float f) {
super.textSetTransform(1, 0, 0, 1, 0, 0);
}
}