Live data from Hacker News

OpenPDF 1.3.0

github.com

21–30 of 63 posts

Re: OpenPDF 1.3.0

#21
post #10

Earlier quoted context omitted.

There's already plenty of open source implementations of PDF parsing: Ghostscript, MuPDF, XPDF, Poppler, Pdfium, just to name the first few that come to mind.

All do not support typewriter or forms. This makes easier to fill up forms

MuPDF supposedly supports forms in the latest version.

I’ve never seen it work though.

Re: OpenPDF 1.3.0

#22
post #8
post #6

Earlier quoted context omitted.

What's wrong with pdfium?

It uses custom google build systems that are difficult to use independent of a chromium build. Last time I tried I was unable to get it to build. 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.

> Not sure if it has a stable interface

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!

Re: OpenPDF 1.3.0

#23
post #2

Pdf so badly needs a standard open source reference implementation. the problem with java is that it isn’t easy to reuse in other programming environment... something in C, or anything that compiles through LLVM would probably be a better choice i think.

You can compile java to LLVM or create dll/so files.

* https://www.graalvm.org/

* 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.

Re: OpenPDF 1.3.0

#24
My particular needs for PDF creation are somewhat unusual, so I'm not surprised that Acrobat Pro seems to be the only thing that suits my needs. If anyone knows of a PDF creation library that has good support for the various image compression schemes supported by PDF, I'd love to know about it.

Currently I'm using a 10 year old paid version of Acrobat Pro because I'm unwilling to spend another $500 to get a modern copy simply to compress images. I use it for scanning and archiving old computer manuals. In many cases jbig on 1bpp images is good enough; other times I want to use one of the more sophisticated hybrid schemes so I can have B&W or color images interspersed on the page with 1bpp text. Acrobat does a pretty good job of auto-deskewing images and doing analysis to figure out which compression type to use in different sections of the same page.

Re: OpenPDF 1.3.0

#25
post #20

Earlier quoted context omitted.

Google's PDFium which is used in Android and ChromeOS is fast becoming the reference implementation to target: https://opensource.google.com/projects/pdfium

pdfium has literally no documentation. but the good thing is that it is c which can be called from many languages.

"No documentation" seems a bit harsh - there's a Getting Started guide in docs/ [0] and fairly good commenting on the interfaces in public/ [1]

[0] https://pdfium.googlesource.com/pdfium/+/refs/heads/master/d...

[1] https://pdfium.googlesource.com/pdfium/+/refs/heads/master/p...

Re: OpenPDF 1.3.0

#26
post #22
post #8

Earlier quoted context omitted.

It uses custom google build systems that are difficult to use independent of a chromium build. Last time I tried I was unable to get it to build. 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.

> Not sure if it has a stable interface 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!

> We endeavor to keep these as stable as possible.

That sounds more like best-effort.

Re: OpenPDF 1.3.0

#27
post #2

Pdf so badly needs a standard open source reference implementation. the problem with java is that it isn’t easy to reuse in other programming environment... something in C, or anything that compiles through LLVM would probably be a better choice i think.

I really feel this when working in python. It feels like there are a million tools that each support 1/3 of the standard.

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.

Re: OpenPDF 1.3.0

#28

My particular needs for PDF creation are somewhat unusual, so I'm not surprised that Acrobat Pro seems to be the only thing that suits my needs. If anyone knows of a PDF creation library that has good support for the various image compression schemes supported by PDF, I'd love to know about it. Currently I'm using a 10 year old paid version of Acrobat Pro because I'm unwilling to spend another $500 to get a modern co…

This doesn't completely fix your issue, but since you mentioned deskewing, I clean up my scanned documents using ScanTailor Advanced:

https://github.com/4lex4/scantailor-advanced

I find the autodeskewing algorithm to work well, but it allows hand adjustment as well, which I like. As I've gotten better as using it, I've been able to get the size of my scanned documents down considerably by cleaning up the scans. This includes some old manuals.

As far as the pdf encoding itself, I use both mutool, from mupdf, and qpdf. I just checked and it looks like while they both compress their streams, it may not have the same flexibility with Acrobat Pro. For me, I'll decompress, edit, and recompress streams on the files and that's been fine for my use.

That said, if someone knows of a better tool for compressing streams in a PDF, I'd be interested to hear about it as well.

Re: OpenPDF 1.3.0

#30

My particular needs for PDF creation are somewhat unusual, so I'm not surprised that Acrobat Pro seems to be the only thing that suits my needs. If anyone knows of a PDF creation library that has good support for the various image compression schemes supported by PDF, I'd love to know about it. Currently I'm using a 10 year old paid version of Acrobat Pro because I'm unwilling to spend another $500 to get a modern co…

It sounds like you are using Windows, but if you happen to be using Linux [1]:

    ps2pdf LARGE.pdf SMALL.pdf
I believe it compresses all of the images independently, instead of converting the entire thing to an image as I believe Imagick does (I could be wrong though). This tool doesn't appear to have any intelligent auto-deskewing though. (On a slightly different note, it's questionable whether you want to do this for archiving as it'll undoubtedly be a lossy operation.)

The reason I use this: Many websites for conferences have upload limits at around 10MB, a size you can easily reach with a handful of images from a modern device in your paper.

[1] https://www.shellhacks.com/linux-compress-pdf-reduce-pdf-siz...

Post reply on HN