something in C, or anything that compiles through LLVM would probably be a better choice i think.
* https://www.graalvm.org/docs/reference-manual/aot-compilatio...
You only need to pass `--shared`. (You can also define multiple exports via public static ... and some annotations https://github.com/oracle/graal/blob/master/substratevm/READ...) of course it's a little bit akward to first create a "JVM" library and then call that library from native code, but it's not impossible.
[0] https://pdfium.googlesource.com/pdfium/+/refs/heads/master/d...
[1] https://pdfium.googlesource.com/pdfium/+/refs/heads/master/p...
E.g. I recently needed to convert raw OCR files to PDF -- place TIFs on each page without recompressing, place invisible text on top, add bookmarks, save. I ended up stringing together three python libraries (img2pdf for efficient image combining, reportlab to place text, PyPDF2 to merge the two), which was both clunky and slow. Second pass was scripting command line tools (tiffcp + tiff2pdf + reportlab + pdftk), which was still clunky but at least faster.
It would be awesome if there was one solid, fast implementation that lots of language ecosystems could wrap and contribute back to. I haven't looked around much outside of Python -- maybe that's OpenPDF with Graal, or PDFium, or something else mentioned in the sibling comments? But there are so many usecases for PDF, I wouldn't be surprised to find that those also fail to cover the whole field.
Y'know what I can imagine working is a package ecosystem that uses a common in-memory data structure, so you have one base package that does the reading and writing and low-level manipulation, and someone else can come along and write the equivalent of img2pdf or reportlab as separate packages that compose without any efficiency loss. That could work in any language but it feels like the kind of thing Rust is doing really well these days. It might just take some good branding around "hey, here's a low-level FooPDF data structure that is easy to write high-level libraries against -- make sure to mention in your docs that you're compatible with FooPDF." Sort of an Apache Arrow approach.
Similarly, I would like to see more attention given to PDF/A and high quality reference implementations and libraries targeting it. It solves many of the most common complaints here on HN about PDF: no audio / video, no javascript, no XML forms, all fonts have to be embedded, etc. - and it's an ISO standard.
We really need solid support for a document format that has readers that aren't constantly getting CVE'd from supporting too much of a bloated specification.
Pdf/a needs a LOT more publicity.
I’ve never seen it work though.
https://www.iso.org/obp/ui/#iso:std:iso:19444:-1:ed-1:v1:en
Though, it was mostly an exercise in frustration. That said, IRS forms used to work great with this.
However, long story short, Evince works most of the time.
I feel that the name is very unfortunately chosen - it's too generic, should have had a "J" in it at least to denote that it is a Java library. JOpenPDF, perhaps.
It's not packaged as far as I can tell separately from chromium and chromium doesn't ship it as a reusable library. Not sure if it has a stable interface, probably not.
It doesn't have any frontend other than chromium.
Their docs say
"The public/ directory contains header files for the APIs available for use by embedders of PDFium. We endeavor to keep these as stable as possible."
The rest are valid points though!
That sounds more like best-effort.
Isn't one of the advantages of Java exactly being multi-platform?
You target the JVM. So Java libraries are awkward to call from e.g. C++ or Python.