log4j:WARN No appenders could be found for logger (org.apache.pdfbox.util.ResourceLoader).
log4j:WARN Please initialize the log4j system properly.
This message means that you need to configure the log4j logging system. See the log4j documentation for more information.
PDFBox comes with a sample log4j configuration file. To use it you set a system property like this
java -Dlog4j.configuration=log4j.xml org.apache.pdfbox.ExtractText <PDF-file> <output-text-file>
If this is not working for you then you may have to specify the log4j config file using a URL path, like this:
log4j.configuration=file:///<path to config file>
No! Only one thread may access a single document at a time. You can have multiple threads each accessing their own PDDocument object.
You need to call close() on the PDDocument inside the finally block, if you don't then the document will not be closed properly. Also, you must close all PDDocument objects that get created. The following code creates two PDDocument objects; one from the "new PDDocument()" and the second by the load method.
PDDocument doc = new PDDocument();
doc = PDDocument.loadPDF( "my.pdf" );
if( doc != null )
Check whether the character is available in WinAnsiEncoding by looking at the PDF Specification Appendix D. If not, but if it is available in this font (in windows, have a look with charmap.exe), then load the font with PDType0Font.load(), see also in the EmbeddedFonts.java example in the source code download.
I'd like to use PDFBox to create a complex layout containing several paragraphs, tables, images etc. Is PDFBox fit for that purpose?
PDFBox being a low level PDF library provides the APIs to create page content such as text, images etc. But at this point in time it doesn't provide a higher level API to do page layout, paragraph handling, automatic line wrapping or create tables and such.
But PDFBox is the foundation of some projects which might help in that case. This includes projects such as
You may also want to consider using Apache FOP which allows to create complex documents from XML data and templates-
Make sure that you closed your content stream before saving.
By default, text extraction is done in the same sequence as the text in the PDF page content stream.
PDF is a graphic format, not a text format, and unlike HTML, it has no requirements that text one on page
be rendered in a certain order. The order is the one that was determined by the software that created the PDF.
To get text sorted from left to right and top to botton, use
Text extraction from a pdf document is a complicated task and there are many factors involved that effect the possibility and accuracy of text extraction. It would be helpful to the PDFBox team if you could try a couple things.
This is because the characters in a PDF document can use a custom encoding instead of unicode or ASCII. When you see gibberish text then it probably means that a meaningless internal encoding is being used. The only way to access the text is to use OCR. This may be a future enhancement.
This probably means that the "Resources" directory is not in your classpath. The Resources directory is included in the PDFBox jar so this is only a problem if you are building PDFBox yourself and not using the binary.
PDF documents have certain security permissions that can be applied to them and two passwords associated with them, an user password and an owner password. If the "cannot extract text" permission bit is set then you need to decrypt the document with the owner password in order to extract the text.
Not really, for a couple reasons.
The memory footprint depends on the PDF itself and on the resolution you use for rendering. Some possible options:
-Xmx value when starting java
PDFRenderer.renderImage(), or the dpi value when calling
PDImageXObject objects by calling
PDDocument.setResourceCache() with a cache object that is derived from
DefaultResourceCache and whose call
public void put(COSObject indirect, PDXObject xobject) does nothing. Be aware that this will slow down rendering for PDF files that have an identical image in several pages (e.g. a company logo or a background). More about this can be read in PDFBOX-3700.
This is because in some PDFs (e.g. the one in PDFBOX-2814, text is not rendered directly, but as a shaped clipping from a background. Java graphics does not support "soft clipping" https://bugs.openjdk.java.net/browse/JDK-4212743, and because of that, the edges are not looking smooth. Soft clipping could be achieved with some extra steps, but these would cost additional time and memory space. You can have a higher quality by rendering at a higher dpi and then downscale the image.
Sadly, this is a known bug in Java Imaging. Use the twelvemonkeys library as described in the dependencies page.
Thanks to contributions we have supported Bengali and Latin ligatures since 3.0.0. Starting with version 3.0.2 we also support Devanagari and Gujarati. However there are some caveats: PDFBox will support only one language in a specific font, thus it is best to use a font that is specific enough, e.g. the Lohit fonts. For example, the Mangal font is meant to be a Devangari font, but PDFBox will choose Bengali because that one is also claimed to be supported and is checked first. It is not possible to deactivate the feature. The features may be incomplete because we do not yet support all GSUB tables, and we don't support GPOS at all.