Apache PDFBox – A Java PDF Library | Hacker News Reader

Apache PDFBox – A Java PDF Library

pdfbox.apache.org

151 pointsrkda56 comments

I always found SVG (plus the Inkscape CLI) to be the best interface for generating PDF documents.

I'm sure there are arguments in favour of libraries like this such as performance or better control but when all you need is to generate a simple invoice with a couple of dynamic fields, just use Inkscape to draw your template and your favourite XML library to put values in it in your code. When you need the PDF, use inkscape --export-pdf to get your PDF document.

SVG also makes it quite easy to show an in-browser preview of the generated document before performing the actual conversion, avoiding a costly PDF generation most of the time.

Interesting. So do you run inkscape manually from a command line or shell out to it from a program? And I guess that would not scale well f you want to generate many PDFs, in the sense of running inkscape each time would be a perf hit?

It seems that it would scale just find with RabbitMQ, and worker queues. It may not be maximum performance per node... but that's not the same as scalability.

I guess if you have enough hardware resources, and the delta is low, it may not matter.

After all, we run Unix commands tens or hundreds of times a day, alone or in pipelines, to get things done, vs. putting all the needed functionality into one program and calling it.

Various pros and cons exist for both approaches ...

We use FOP for document-shaped stuff, and it's worked out pretty well for us. But I could see using SVG when you want a single page with complex layout (esp. rotated text, etc.)

For an invoice with a couple of fields filled in, you could also consider using a PDF form. (And use a library like iText or pdfbox to fill it in.)

I used PDFBox a few weeks ago to dynamically annotate a set of PDFs. The library works well; but it is severely under-documented. Also, the API is asymmetric w.r.t. get/set in several places. After several hours of frustration, I had to look up the PDF specification for constants to set for default appearance, _etc_., and then set them directly in the underlying COSObject dictionary.

Despite a few problems, the library is good. I will certainly use it again.

Edit: I used 2.0.0-RC1.

I used to use a Play framework module to create simple PDFs. You just do your formatting in html and render it as a PDF. https://www.playframework.com/modules/pdf (only for 1.x series). There seems to be a version for 2.x series but I have never used it(https://github.com/innoveit/play2-pdf).

We outsourced this to DocRaptor (http://docraptor.com) - we just call an API with our HTML and CSS, get back pretty invoices.

Which is just a SaaS version of PrinceXML (http://www.princexml.com/)

I do the same but using the flying-saucer library. Just pass the HTML text (with CSS) and it gives back a PDF. Up to a certain point the limitation was getting the header row of multipage tables to appear i every page. When they got to implementing support for CSS 2.1, worked like a charm. Headers and Footers (witblh page numbers) work too.

What? People still us Flying Saucer?!

I see that they have released 2.0 lately, but can't find any dates, nor the improvements over 1.x. Is this the news? A press release would be better, probably. It's not [Show HN], it's an established Apache project, so I don't get what the news is here.

Their "Migration Guide" [1] contains a list of improvements. They should probably add a date to their pages, but reading their mailing list the release is at most a few days old.

[1]: http://pdfbox.apache.org/2.0/migration.html

The download pages do have dates, albeit you have to hunt to find them:

http://mirror.vorboss.net/apache/pdfbox/

  [DIR] 1.8.11/                 2016-01-17 21:55    -   
  [DIR] 2.0.0/                  2016-03-18 12:02    -

I've used that at the startup I work, had to move from 1.x to 2.0 because the font support is miles better. Don't know about other minor improvements. Eventually we switched to https://mozilla.github.io/pdf.js/ because it makes for a much smoother experience overall for our use case (import pdfs into a lookbook, is a webapp for designer)

While it's interesting to look for the latest changes in this project, even if there were none, it would still be a very valid submission since HN isn't specifically a news website.

In fact, I see so many "what's the news" posts that I sometimes think they should change the name!

Sorry, here's the link to the press release:

https://blogs.apache.org/foundation/entry/the_apache_softwar...

Anyone has a solution to make pdf from html thats hosted. The java library flyingsaucer is stuck at css 2.1 and not much maintained. I have been meaning to check wkhtmltopdf which will need launching a process but might be the best bet for such work. Anyone has better experience in doing something similar?

wkhtmltopdf works quite well, I've used it before. A bit of a hassle to get it compiling though.

I have also had great success with wkhtmltopdf. There are pre-built binaries available too: http://wkhtmltopdf.org/downloads.html

http://www.princexml.com is very good for complex multipage documents but unfortunately it's very expensive.

I've used phantomjs through the command line for generating pdfs from html using the screen capture functionality (http://phantomjs.org/screen-capture.html).

I implemented this over the weekend using a small VM instance from Google Cloud + PDFBox 2. I set up Apache, wrote a quick PHP script that takes in the URL of the PDF to be converted, downloads it, converts it to HTML with PDFBox and then prints the HTML. I then linked this small piece into a bigger system that uses the converted HTML.

I used wkhtmltopdf on a project, custom built a version of bootstrap from the less files purely for outputting via wkhtmltopdf, it worked really well and produced some nice looking PDF's.

https://youtu.be/TC_uv_AD808?t=1m31s all the PDF's in that video where generated, that was an early alpha of the product.

phantomjscloud.com, there's a html-to-pdf example on the front page.

disclaimer: i wrote it

I'm surprised more people aren't simply trying to use TeX or LaTeX to generate dynamic PDFs. Most of the libraries I've looked at historically were comically incapable, limited to basics like "place a single line of text at these coordinates," with no provisions for line wrapping, paragraphs, tables, etc.

LaTeX (or any TeX variety) on the other hand give you so many different powerful features to generate any arbitrary document, and not only in PDF. There are, of course, a few associated risks that would need to be mitigated as with anywhere user input gets compiled in some turing-complete system, but I'd imagine it would be fairly straightforward to make sure input gets properly escaped so an attacker couldn't run arbitrary code.

PDFBox is quite good at extracting text from pdfs. When I use PDFBox, it is for extraction.

Maybe this has changed with newer versions of PDFBox, but 5+ years ago, the internet wisdom was to use PDFBox for extraction and something else, like a version of iText that suited your license needs, for generation.

As much as I like LaTeX, if you have made no prior time investment in typesetting with it, it is not trivial to produce custom good-looking output with it.

Have you tried using (La)TeX in a real world project? Would be cool to hear from someone on whether compilation time is an issue. Some TeX packages have a quite severe impact on performance.

For many of our reports, we've been using FOP (Apache's XSL-FO implementation). It's an XML format, similar to HTML, with stuff like page masters to help with layout. We generate the XML with a velocity template, feed it into FOP, and which generates the PDF.

>"Most of the libraries I've looked at historically were comically incapable,"

He apparently did not look at iText, which can generate docs with support for all major fonts and bidirectional writing, forms (interactive and not), and sign them digitally.

It would be nice to see a feature diff with itext.

iText can be somewhat frustrating to work with, so it would be great if this is a viable alternative.

In what ways did you find it frustrating?

Really? I've used iText for years. It is extensively documented both online and in the 600-page book from Manning and the guys who wrote the library answer questions on SO, most being answered in less than 24 hours. In addition, iText has both a high-level API and a low-level interface, so anything you can do in a PDF you can do with iText. I'd be hard-pressed to think what could be frustrating about it. That doesn't match my experience at all.

iText is very expensive when used in commercial products. It has a AGPL license, but costs for commercial use.

There is an older version still available under a less restrictive license, although it's not always easy to find.

For one thing, iText has both Java and .NET implementations. Also, iText also has excellent documentation (both online and third-party books) and the authors answer questions all the time on SO.

And if you're looking for commercial software that produces PDFs right in the browser, see http://demos.telerik.com/kendo-ui/pdf-export/page-layout

Disclaimer: I'm part of the team. Also see http://docs.telerik.com/kendo-ui/framework/drawing/drawing-d...

Hopeflly PDFBox is more stable than Apache Tika. Tika has become bloated with all the different formats that it supports.

Latest version of Tika parser has 44 compile time dependencies: http://mvnrepository.com/artifact/org.apache.tika/tika-parse...

The scope of Tika is different and wide. For the PDF subset, Tika uses PDFBox to parse and extract data from the document.

I have never noticed that. Perhaps it is because I never used Tika directly, but as a dependency from other projects such as Nutch.

I realize the scope is different, which is why I mentioned that Tika supports more formats.

As sigmaml said, Tika uses PDFBox. I would still recommend using PDFBox for text extraction until Tika updates to PDFBox 2.0. The biggest difference I have found with PDFBox 2.0 versus 1.x is that there are significantly fewer blank lines in the 2.0 output. This helps with readability and further processing on the output such as detecting headings, paragraphs, etc.

> Hopeflly PDFBox is more stable than Apache Tika.

I've had a few issues with Tika (at least one of which turned out to be a PDFBox issue). The mailing lists and bug trackers have been very helpful - down to people fixing bugs or writing me custom code to work around the issue, often in a few hours.

Very impressed, and the atmosphere reminds me of my first few years on the web: people helping each other, before it became so commercialised.

Just in case there are any posts about the complexity of using any pdf library, you need to understand that the PDF spec itself is an almost unimaginable monster of complexity and frustration.

Can we use PDFBox to convert microsoft formats like .doc, .docs, .ppt, .pptx, etc to PDF?

I am struggle finding some good solution with the same.

Their website doesnt have any proper answer to this.

It doesn't seem to have that feature, no.

Windows 10 and OS X have built in PDF printers now.

What if I need to do this programmatically?

Is the Windows 10 PDF printer better than the MS Office integration?

Because the MS Office PDF integration is shit, when I get such PDFs in Preview on Mac OS X and then want to print it.

PDFBox can't do that.

Apache OpenOffice API used to be able to do this. Not sure about output quality. Also not sure if LibreOffice API too supports it.

You might also want to evaluate a commercial framework like Aspose [1] (not affiliated, I've just come across their marketing pieces)

[1]: http://www.aspose.com/docs/display/slidesnet/Converting+Pres...

There's quite a few solutions to do this, from PDF printers (eg CutePDF) through to alternative office suites (eg LibreOffice supports exporting to PDF).

However by far the easiest for you might just be to use the Microsoft Office addin that allows you to print to PDF[1]

If you need to do this programmatically then you could use the LibreOffice command line tools for converting files[2]

[1] https://support.office.com/en-us/article/Print-share-and-pro...

[2] https://ask.libreoffice.org/en/question/2641/convert-to-comm...

FWIW I just launched a web service API for doing that - https://documentalchemy.com/

If you're comfortable with an external API for this, converting MS Office documents to PDF is as simple as:

      curl -X POST --form "document=@$SOURCE" -H "Authorization: da.key=$API_KEY" https://documentalchemy.com/api/v1/document/-/rendition/pdf -o "$DEST"

You can test it directly online here - https://documentalchemy.com/demo

If you're not comfortable with an external API for this, I think the conventional answer to your question is to use unoconv [1] which is simply a Python script that uses LibreOffice [2] or OpenOffice (formerly StarOffice) [3] to do the conversion.

[1] https://github.com/dagwieers/unoconv

[2] https://www.libreoffice.org/

[3] http://www.openoffice.org/

You can also use Libre/OpenOffice directly for the conversion, but unoconv is geared toward having an always-on version of office running in the background that you use for the conversion, which is a significant performance boost relative to launching the app for every conversion.

unoconv is a little flaky, but works well in general (it's certainly a part of the DocumentAlchemy backend).

If you needed to stay open source, you could probably wire something up with Apache Poi to handle the msft end of that and pdfbox to handle the pdf end (edit: I mean read the msft file with poi and write out equivalent info using pdfbox into a pdf). It might be ugly, but with enough effort it may work.

Where I work, we ended up paying for the commercial Aspose products. Example doc to pdf code: http://www.aspose.com/docs/display/wordsnet/How+to++Convert+...

Any feedback on how this compares to Reportlab in Python or Prawn in Ruby?

PDFBox can read and render (to an image) pdfs in addition to generating them. I don't know how feature-complete it is.

Can it be compiled with GWT?

PDFBox does not seem to depend on anything but the JDK (1.6) and commons-logging, so it might work if you manage to find a working and matching version of commons-logging for GWT, and if PDFBox only uses the JDK parts supported by GWT. That is a pretty big if though. I doubt someone bothered to port this to GWT, but who knows, you may be in luck.

If you are trying to generate PDFs in a web-application, I would delegate this task to the back-end.

It uses AWT (1) so no it won't work with GWT.

[1] https://github.com/apache/pdfbox/search?utf8=%E2%9C%93&q=awt

Reply on news.ycombinator.com