Slashdot Mirror
Ask Slashdot: Best PDF Handling Library?
New submitter Fotis Georgatos (3006465) writes I recently engaged in a conversation about handling PDF texts for a range of needs, such as creation, manipulation, merging, text extraction and searching, digital signing etc etc. A couple of potential picks popped up (PDFBox, itext), given some Java experience of the other fellows. And then comes the reality of choosing software as a long term knowledge investment! ideally, we would like to combine these features:
- open source, with a community following ; the kind of stuff Slashdotters would prefer
- tidy software architecture; simple things should remain simple
- allow open API allowing usage across many languages (say: Python & Java)
- clear licensing status, not estranging future commercial use
- serious multilingual & font support
- PDF-handling rich features, not limiting usage for invoicing, e-commerce, reports & data mining
- digital signing should not go against other features
I'd like to poll the collective Slashdot crowd wisdom about if/which PDF related libraries, they have written software with, keeps them happy for *all* the above reasons. And if not happy with that all, what do they thing is the best bet for learning one piece of software in the area, with great reusability across different circumstances and little need for extra hacks? I'd really like to hear the smoked out war stories. It is easy to obtain a list of such libraries, yet tricky to understand whethe people have obtained success with them!
Python only, but I've used it successfully.
Well, there's PDFLib, which is hideously expensive and not open source, but if you're after a professional package for serious purposes that just works I can only recommend it.
To be fair the OP does say "ideally."
Because those are hisrequirements and there is nothing wrong with that but it is to you so don't use open source. See your problem is solved.
My karma is not a Chameleon.
pdf.js is great for parsing and manipulating pdfs.
I can't go into great detail as to how I've used it (Still under NDA), but it's rendering and manipulating of pdfs is pretty darn good.
As for converting office formats to pdf, your best bet is to use office automation. It can be built to scale up, but it needs a lot of work to do so.
I've found these tools useful, with an honorable mention to gnupdf. I've never used it personally, but the code looks pretty solid. That said, when I really needed to produce great multilingual PDF I pulled out the PDF spec, gritted my teeth, and generated it directly.
leptonica - turn images into PDF
tesseract - turn images into searchable PDF
qpdf - linearize PDF for random access over HTTP
jhove - basic validation
jhove-pdf-a - validation with better compatibility guarantees
pdftk - command line tool for splicing pages together or apart
ttx/FontTools - tool for modifying custom fonts
reportlab - python library, easy to use but works best with Latin scripts
You might try IText:
http://en.wikipedia.org/wiki/IText
pdftk uses it.
The best PDF software I've ever used is Prince XML.
For years, we got by with HTMLDoc but finally dumped it because we absolutely needed unicode support.
After trying many different packages, we settled on Prince. Our main constraints were performance related which you apparently aren't worried about, so maybe it's overkill for what you need.
libpoppler works; it just only meets the requirements that libpoppler was designed for. It correctly displays most PDFs, but fails with esoteric features used only in a small subset.
In that sense, libpoppler is like a swiffer mop: it handles most normal dirt, dust, and general cleaning needs for tile and hardwood; but you will need a mop, or potentially nylon or bristle scrubbers and power tools, to clean some deep-set grime from linoleum or porcelain tile. I've had mops fail to clean traffic grime from kitchen linoleum, at all; stuck a drill brush in a 3000RPM 600W output cordless drill and blasted that shit right off.
Support my political activism on Patreon.
Yes ... and their principles are; I want somebody else to do a lot of hard work and I want the benefit for free. Oh, and I don't even want to research this myself, I want others to do the work ... for free.
See, now thanks to you I have to clean all this coffee off my monitor...
Make this becomes a requirement: support for making PDF/A.
At least on the C# side of things, the three libraries I've used (iTextSharp, PdfSharp, and Aspose.Pdf) are all a bit of an unintuitive mess with inconsistencies all over the place and very little documentation. In the case of iText, their revenue stream is putting all their documentation into a book for people to buy, so it's not uncommon to get an intentionally vague response when asking for help.
I cycle between each depending on what I need to do, because they all have their own quirks and supported features. I've even piped from one to another to get certain parts of the process working.
Good luck.
sudo apt-get install ghostscript pdftk poppler-utils
ghostscript: /usr/bin/dvipdf /usr/bin/pdf2dsc /usr/bin/pdf2ps /usr/bin/pdfopt /usr/bin/ps2pdf /usr/bin/pdftk /usr/bin/pdffonts /usr/bin/pdfimages /usr/bin/pdfinfo /usr/bin/pdfseparate /usr/bin/pdftocairo /usr/bin/pdftohtml /usr/bin/pdftoppm /usr/bin/pdftops /usr/bin/pdftotext /usr/bin/pdfunite
ghostscript:
ghostscript:
ghostscript:
ghostscript:
pdftk:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
poppler-utils:
iText has some problems with licensing for commercial applications and government projects. I am looking for an alternative.
Well, he's dealing with PDFs, so he doesn't have *strong* principles.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Other people have politicians that require you to use open source if available.
open source, with a community following ;
Why? So if you find one that fits every other requirement but this one you will refuse to use it?
Derp,
Probably because if there is no community following it there is not going to be much in the way of development going on.
I use a cordless drill and brush bit to make my PDF files, too. It's slow, and it doesn't really scale well, but at least it's not from Adobe.
You are welcome on my lawn.
itext may be one of those. It comes under AGPL and under a commercial license if you buy support from the company.
You can't handle the truth.
Indeed. I'm curious why is not "closed source, with a strong industry support" an option?
Because both "open source" and "strong industry support" when put together like that pretty
much means that they don't want to get stuck holding the bag if the company goes out of business.
With "strong industry support" the odds of a company going out of business is minimized and
with "open source" even if it does go out of business then you can still continue to use the
software indefinitely while you look for a replacement.
PDFLib GmbH (german LLC) build exactly one product: PDFLib. And they've been doing that since 1997. AFAIK the company was run by one guy - the initial developer - alone for most of the time. Now it's probably a shop of 5 or so.
So it's not FOSS - yeah, that's a real shame. But the devs get to eat, you can demand service and response if you run into a bug and you can expect a good product and with PDFLib you're probably going to get it too.
I haven't come across a single project doing non-trivial PDF stuff that doesn't use PDFLib. I've used it myself a little, and the cookbook that comes with the product was very good, so it comes recommended.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
Probably because if there is no community following it there is not going to be much in the way of development going on.
Right. With mid-tier open source projects, there's a good chance they're either unfinished or abandonware. (Lower-tier open source projects are both.) There's only so much attention available.
Java-only. Commercial. Feature-rich. Great company name.
PDF isn't so bad, is it? It's an open standard with open source implementations, with open/royalty-free licensing for the patents involved. Or am I missing something?
Comment removed based on user account deletion
Specially if you need to extract data from it
That's not what it's for, is it? Except by the method of reading, with your eyes.
systemd is Roko's Basilisk.
Because maybe it's not his first project? Fine, let me ask you: how many times did you get burned by totally unmaintainable third-party dependencies, before you vowed "NEVER AGAIN will I get so utterly fucked over?"
Was your fifth project the one where you couldn't ever port to a new architecture or OS, or was it the one where the only company who had the source, went into bankruptcy and it took years for the liquidation to happen and you never really figured out where the assets are? No wait, your fifth project was the one where they just withdrew it from the market for "strategic reasons" and you never found out why and there was no replacement. Ah, then there was the race condition that you knew you could find if only you could read through the code, but the sole developer didn't even know what "race condition" means so he ignored your bug report. And the time the DRM server incorectly said the API key had expired so you didn't get any sales that day. Then there was that time you had the source but weren't allowed to change some parts of it: I loved the comment "by reading this you are violating the License Agreement" followed by the base64 string of dynamically interpreted code. Of course you violated the agreement, and decoded it: finding a bug you weren't allowed to fix. And of course let's not forget the time the developer might have actually hypothetically allowed the code to be maintained or might have even done it himself, but he had lost it, the one and only copy in the entire world, which had been used to compile the code that literally tens of thousands of people were depending on. That one's a classic, almost right up there with the vendor who died, taking all his customers' hopes of maintenance with him to the grave.
Holy crap. I get why the public doesn't know to demand Free Software. Even smart people can be uninformed or lack expertise outside their areas. But developers, really? You have to be LITERALLY STUPID to not see "open source" as at least a major advantage, if not necessarily always the winner. Maybe it's not always a solid requirement, but if you don't always at least start your searches that way and try to get something that at least can be maintained, then yes, you're a moron.
"Oh no, I'm not a moron," you explain, "I just happen to think that some large projects aren't ever going to need maintenance, because surely it's simple enought that a good programmer will get everything right the first time." You're right: you're not a moron; you're an imbecil. Sorry about the mistake.
I'm using a non-free, but source-provided library called Clib-PDF. It's a pretty nice library with a pretty easy API, and even has PHP bindings (so it must've been a viable mainstream choice at one point). But somehow the company (or was it just a single guy) disappeared years ago. Luckily, we paid for and got the source, and I've been able to keep using it (and even fixing things in the source) without any ongoing support. So not quite open source, but not quite the disaster of discontinued closed source.
I suspect that the author of this library sold it to one of the commercial companies who proceeded to shut down a viable competitor. But who knows...
Posted from my Android phone. Oh, I can change this? There, that's better...
Some people have principles.
He could be working on an open source project
We used PDFClown (open source - Java) for production applications that were generating PDF's on the fly with hundreds of pages using Java and it performed very well.
The Truth is a Virus!!!
iText meets some of your criteria.
* open source, with a community following ; the kind of stuff Slashdotters would prefer = yep. Including several commercial books .NET. Not a good fir for dynamic languages.
* tidy software architecture; simple things should remain simple = It's big and complete.
* allow open API allowing usage across many languages (say: Python & Java) = Native Java. iText# is a port to
* clear licensing status, not estranging future commercial use = AGPL + commercial license. Clear but not free as in beer for commercial.
* serious multilingual & font support = yep.
* PDF-handling rich features, not limiting usage for invoicing, e-commerce, reports & data mining = yep
* digital signing should not go against other features = has several singing modules. Excellent.
I started with Reportlab (the open source parts), found it to low level so I considered using the commercial edition because it has a templating language. As I was not very fond of investing time in learning yet another templating language, I reconsidered, and gave HTML with CSS a try for printing. I used wkhtmlpdf for a while but switched to WeasyPrint in the end: it was created for using HTML with CSS for printing, seemed to be more actively developed when compared to wkhtmlpdf.
Does anyone have experience with MuPDF? http://www.mupdf.com/ It's open-source, but requires license for commercial use. It appears to offer the best performance and portability. Its top level application(MuPDF) is highly rated across most platforms: Google Play, Apple Store and Ubuntu.
Is there anything that can handle the gruesome CT600 forms that the UK Tax authority require us to fill in every year? These have lots of embedded scripting and can only be read with Acrobat Reader. However, this year, Adobe have stopped releasing Acrobat for Linux.
(An added bonus, the internal logic of the CT600 is buggy: for example if a particular tax option does not apply, it is fussy about the distinction of 0 vs empty, and this leads to subsequent validation errors (naturally with confusing messages). It also has about 20 pages of irrelevant data required, in order to reach a single number, which we have already calculated.)
Adobe pushes PDF as a method of data collection. People make fancy PDF forms and e-mail them out. Inside of the form is a button that says "when complete, click here to submit form" which attaches the filled out form to an e-mail and sends it back to the publisher. From there, folks somehow extract the fields from the file and dump it into a database, which seems like a messy and complicated process. Honestly a web form would be easier to implement in many cases.
I've seen commercial programs actually do this to support PDF report generation. They just leverage the existing code they have for printing reports and redirect it to a virtual printer. I think it was the Amyuni libraries which are clearly closed source. One thing I can say is that a virtual printer that directly generates PDF files from the GDI output (we're talking Windows here) tends to create cleaner output files (smaller size, less rendering errors) than the Postscript printer output to PDF route.
Oh, and I don't even want to research this myself, I want others to do the work ... for free.
Thats a bit unfair. I had a need to convert some output into PDF a while back and started looking thru the many proprietary and open source options, and there were a lot to choose from. It was awfully hard to determine which were quality and which weren't. Installing and trying to program a working solution against each API would have taken up a huge amount of time. There is nothing at all wrong with asking if others have been thru some of that process and found a favorite. I certainly would have liked to see some comparisons or good product reviews to help me decide.
Also, one thing I started to suspect; a number of the supposedly proprietary PDF tools and API's that I investigated appeared to just be a GUI and some wrappings around a GPL PDF library, usually Ghostscript, with little or no attribution given. Once again, there is nothing wrong with asking for other peoples experience with these tools and libraries; you don't want to find out you have breached GPL licensing AFTER you have created your solution, do you?
If I had a DeLorean... I would probably only drive it from time to time.
I needed to layout a novel in a PDF. I've previously worked with iText and prefer not to construct a PDF one element at a time. I wanted an HTML to PDF workflow. I then tried wkhtmltopdf, but it doesn't support most of the hardcore design needs: hyphenation, widow/orphan control, alternating page margins, and page headers and footers based on the section of a document. PrinceXML supports all that. Writing only CSS, and based on html content, you'll be able to replicate anything a designer can do in InDesign. It's incredibly powerful and the time it saves in development effort more than pays for the high cost of the software.
Not sure how current it is, but when I was looking for the same a few years back all that was really available for PHP was HTML->PDF libraries which were not sufficient for anything but the most basic forms. A decent invoice form was hard to get right with these tools. Then I came across FOP. Or more specifically XML-FOP. Combine that with a little XSL and the output was amazing, and could do more than the HTML converters. The only problem is that the FOP tool was a Java based program so PHP would need to execute a shell command to call it. With tight control of what info was passed to that shell command, it seemed an appropriate trade-off for the job at hand. You can still get FOP in the ubuntu repos - apt-get install fop. The learning curve for FOP is a little steep to begin, but no more than any other XML dialect. And being XML, you have a lot of options in building the required FOP file. I opted to put my data into my own XML file, then utilize an XSL file to convert it if/when needed. More details here: http://xmlgraphics.apache.org/...
dpkg -l | grep pdf | grep lib | grep ii
ii libqpdf13:i386 5.1.1-1 i386 runtime library for PDF transformation/inspection software
When all you have is a hammer, every problem starts to look like a thumb.
How open is it really?
Is it a true open standard like TCP/IP, or more like a rubberstamped "standard" by a single company like OOXML?
What prevents Adobe from adding incompatible features to Acrobat and Adobe Reader, and thus make the PDF unreadable by software that adheres to the so-called standard? For example, last year, I could connect to the danish tax department from my Linux machine, using standard TCP/IP, only to be told that to view my tax returns I would have to install Adobe Reader.
Never have I been told "just buy a computer running Berkely Unix" when asking about TCP/IP, but every time I've asked about opening a PDF file, I've been told to just install Adobe Reader, even though I'm convinced that no computer exists powerful enough to actually run (as opposed to crawl) that peace of crap.
Are both quite good, as they names suggest these are Perl modules though.
PDF is a family of standards. There's a core specification and a set of extensions (including, somewhat confusingly, some that remove functionality). In particular, PDF/A removes some of the crazy things (embedded video, audio and JavaScript) and is intended for archiving. Adobe is the driving force behind the standard, and do add non-standard things to their tools (although via a well-defined extension interface), but they're very careful to differentiate PDF/A because a lot of their deep-pocketed customers care a lot about PDF/A as a long-term archive medium. The vested interests of various governments in PDF/A mean that Adobe will have a hard time pushing things through ISO that would be bad for the standard.
I am TheRaven on Soylent News
libHaru is a free C library (install libhpdf-dev in Debian) which supports generation, annotation, compression, encryption. See http://libharu.org/
I think that means you haven't seen enough PDFS. Adobe makes heavy use of proprietary add ons that only work with Adobe products. Then there are all the security vulnerabilities they can contain.
PDFS are great for internal use, if you create them and you consume them. Dealing with those made by random people kind of sucks. Sometimes you get a pdf that's just composed of images for each page. So no text extraction is possible.
I'm not recommending any libraries for the original poster, because they all suck in their own ways and none of them do everything necessary. Without knowing what the pdfs are he's dealing with, its tough to really recommend anything.
Well.. maybe. Or Maybe not. But Definitely not sort of.
OP here. Somebody is listening ;-)
Nope. It's not how you described it. But thanks to your nice language I need not explain you either :-P
Nothing prevents Adobe from adding incompatible features. In fact, nothing stops Adobe from adding compatible features. We have a use case for U3Ds embedded in PDFs (as per the ISO Standard, 13.6), and I haven't found any PDF reader other than Adobe's that displays that.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Text extraction can be a pain even if the text is not images, due to encodings and text placement. Also, it doesn't take proprietary add-ons to lose all open source viewers I'm aware of: I know of none that support the 3D images in the Standard, chapter 13.6.;
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
At least on the rendering side, I have found MuPDF to be really good and stable: http://mupdf.com/
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
btw. have you ever heard of LRD? Language Restraint Disorder... I've spotted some examples over here: http://slashdot.org/~znrt
OP here. Your concern is very valid and you are not alone, I have the same concerns. However, at the moment we know of no other standard that actually renders alike among zillions of Desktops, smartphones, automated processing agents etc. Can you really replace .pdf format with something of similar functionality AND not ask the majority of users to install X, Y, Z?
I'll be honest that I don't have a broad range of experience with libraries. I've used a couple of html-to-pdf implementations and PDFSharp. The licensing for PDFSharp is very permissive, support can be paid for if required and the library is quite fast. As an aside, it has a cousin, MigraDoc, which produces abstract documents which you can finalise to Office formats, if you need that too.
IMO, there is no perfect tool, but PDFSharp has served me well.
Any number of reasons. A big one is stability. If it's open source, it won't go *POOF* one day. It won't double in price one day. It won't get an ugly redesign with no ability to stick with the version that worked.
Then there's the ability to work out the finer points where the documentation was unclear, greater ability to debug any problems
I can't imagine a good reason that open source with a strong community wouldn't at least be a nice to have for any software.
your nice language
please note that the ad hominem in my comment was rethoric. It was actually referring to the content of your article and the attitude it implies. I think it should be obvious but maybe it is worth pointing it out now.
of course many may have learnt something interesting from the ensuing threads. like with any other discussions. that's the cool thing about fora. but I still find that simply dumping the full set of requirements for your assignement on a public forum isn't professional or nice at all. you can ask what you want but one would expect at least some evidence of effort on your part, too. of course this could be subjective and you might view this differenty. this is just my standard, doesn't necessarily apply to you, so no hard feelings.
and no, I know nothing about "lrd" and googling produces little of relevance, this even has spurred my curiosity a bit about how it relates to you inspecting my posting history. any clarification would be appreciated. peace :)
I think its a most urgent for lot of it and internet related, we wait for more update information in next
I like to use PDFCreator for this purpose. It is on sourceforge here: http://sourceforge.net/project...