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.
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.
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.
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.
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!
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]
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.
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.
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.
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.
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.)
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.
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.
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?
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.
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.
58 comments
[ 2.8 ms ] story [ 137 ms ] threadIf you are trying to generate PDFs in a web-application, I would delegate this task to the back-end.
[1] https://github.com/apache/pdfbox/search?utf8=%E2%9C%93&q=awt
[1]: http://pdfbox.apache.org/2.0/migration.html
http://mirror.vorboss.net/apache/pdfbox/
In fact, I see so many "what's the news" posts that I sometimes think they should change the name!
https://blogs.apache.org/foundation/entry/the_apache_softwar...
I am struggle finding some good solution with the same.
Their website doesnt have any proper answer to this.
Windows 10 and OS X have built in PDF printers now.
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.
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...
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...
If you're comfortable with an external API for this, converting MS Office documents to PDF is as simple as:
You can test it directly online here - https://documentalchemy.com/demoIf 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).
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+...
Despite a few problems, the library is good. I will certainly use it again.
Edit: I used 2.0.0-RC1.
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.
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 ...
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.)
Latest version of Tika parser has 44 compile time dependencies: http://mvnrepository.com/artifact/org.apache.tika/tika-parse...
I realize the scope is different, which is why I mentioned that Tika supports more formats.
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.
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.
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.
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.
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.
disclaimer: i wrote it
Disclaimer: I'm part of the team. Also see http://docs.telerik.com/kendo-ui/framework/drawing/drawing-d...