4 ms·

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

by bsaul 7y ago

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.

MartinMond 7y ago
Google's PDFium which is used in Android and ChromeOS is fast becoming the reference implementation to target: https://opensource.google.com/projects/pdfium https://opensource.google.com/projects/pdfium
- jokowueu 7y ago
  Is there a standalone client based on pdfium ?
- merb 7y ago
  pdfium has literally no documentation. but the good thing is that it is c which can be called from many languages.
  - jsty 7y ago
    "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/docs/ https://pdfium.googlesource.com/pdfium/+/refs/heads/master/d... [1] https://pdfium.googlesource.com/pdfium/+/refs/heads/master/public/ https://pdfium.googlesource.com/pdfium/+/refs/heads/master/p...
bla3 7y ago
What's wrong with pdfium?
- hannob 7y ago
  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.
  - bla3 7y ago
    > 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!
    - yjftsjthsd-h 7y ago
      > We endeavor to keep these as stable as possible. That sounds more like best-effort.
pferde 7y ago
That is actually what I thought this OpenPDF thing was. 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.
maskros 7y ago
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.
- marcthe12 7y ago
  All do not support typewriter or forms. This makes easier to fill up forms
  - swiley 7y ago
    MuPDF supposedly supports forms in the latest version. I’ve never seen it work though.
    - kxyvr 7y ago
      Alright, so I noticed this before and just tried it again. While I can fill in forms, does anyone know how to save them? The man page says "S", but that doesn't work and I remember this causing issues for me in the past.
      - maskros 7y ago
        If you press "a" to open the annotation side panel, there will be a button to save the PDF file if the document has been modified.
        swiley 7y ago
        OMG, MuPDF has annotations now!?
  - kxyvr 7y ago
    Evince can handle forms most of the time. That said, Acrobat allows things like Livecycle (XFA) forms, which are nonstandard and will break just about everything outside of Acrobat. Outside of that, pdftk can handle forms using the forms data format (FDF): https://www.iso.org/obp/ui/#iso:std:iso:19444:-1:ed-1:v1:en 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.
kuu 7y ago
the problem with java is that it isn’t easy to reuse in other programming environment. Isn't one of the advantages of Java exactly being multi-platform?
- gdfasfklshg4 7y ago
  More that Java is a platform. You target the JVM. So Java libraries are awkward to call from e.g. C++ or Python.
- tonyedgecombe 7y ago
  I doubt many people will want to add a jvm dependency just to support a PDF library.
merb 7y ago
You can compile java to LLVM or create dll/so files. * https://www.graalvm.org/ https://www.graalvm.org/ * https://www.graalvm.org/docs/reference-manual/aot-compilation/ 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/README.md#images-and-entry-points 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.
- IloveHN84 7y ago
  That's a bad idea and Windows is still experimental.
JackC 7y ago
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.
bscphil 7y ago
> Pdf so badly needs a standard open source reference implementation 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.
- bsaul 7y ago
  absolutely. I developped a pdf parser myself and only discovered pdf/a on HN after almost a year working on it. Pdf/a needs a LOT more publicity.
tonyedgecombe 7y ago
It would be nice to have something with a permissive license. There are a lot of commercial offerings but the costs make them prohibitive for my projects.
lsllc 7y ago
Go has a number of PDF libraries including GoFPDF which is actually really good and very well rounded. These days you can easily build a "C" interface to a shared library implemented in Go. https://github.com/jung-kurt/gofpdf https://github.com/jung-kurt/gofpdf

by bsaul 7y ago

MartinMond 7y ago

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

jokowueu 7y ago
Is there a standalone client based on pdfium ?
merb 7y ago
pdfium has literally no documentation. but the good thing is that it is c which can be called from many languages.
- jsty 7y ago
  "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/docs/ https://pdfium.googlesource.com/pdfium/+/refs/heads/master/d... [1] https://pdfium.googlesource.com/pdfium/+/refs/heads/master/public/ https://pdfium.googlesource.com/pdfium/+/refs/heads/master/p...

bla3 7y ago

What's wrong with pdfium?

hannob 7y ago
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.
- bla3 7y ago
  > 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!
  - yjftsjthsd-h 7y ago
    > We endeavor to keep these as stable as possible. That sounds more like best-effort.

pferde 7y ago

That is actually what I thought this OpenPDF thing was. 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.

maskros 7y ago

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.

marcthe12 7y ago
All do not support typewriter or forms. This makes easier to fill up forms
- swiley 7y ago
  MuPDF supposedly supports forms in the latest version. I’ve never seen it work though.
  - kxyvr 7y ago
    Alright, so I noticed this before and just tried it again. While I can fill in forms, does anyone know how to save them? The man page says "S", but that doesn't work and I remember this causing issues for me in the past.
    - maskros 7y ago
      If you press "a" to open the annotation side panel, there will be a button to save the PDF file if the document has been modified.
      - swiley 7y ago
        OMG, MuPDF has annotations now!?
- kxyvr 7y ago
  Evince can handle forms most of the time. That said, Acrobat allows things like Livecycle (XFA) forms, which are nonstandard and will break just about everything outside of Acrobat. Outside of that, pdftk can handle forms using the forms data format (FDF): https://www.iso.org/obp/ui/#iso:std:iso:19444:-1:ed-1:v1:en 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.

kuu 7y ago

the problem with java is that it isn’t easy to reuse in other programming environment. Isn't one of the advantages of Java exactly being multi-platform?

gdfasfklshg4 7y ago
More that Java is a platform. You target the JVM. So Java libraries are awkward to call from e.g. C++ or Python.
tonyedgecombe 7y ago
I doubt many people will want to add a jvm dependency just to support a PDF library.

merb 7y ago

You can compile java to LLVM or create dll/so files. * https://www.graalvm.org/ https://www.graalvm.org/ * https://www.graalvm.org/docs/reference-manual/aot-compilation/ 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/README.md#images-and-entry-points 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.

IloveHN84 7y ago
That's a bad idea and Windows is still experimental.

JackC 7y ago

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.

bscphil 7y ago

> Pdf so badly needs a standard open source reference implementation 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.

bsaul 7y ago
absolutely. I developped a pdf parser myself and only discovered pdf/a on HN after almost a year working on it. Pdf/a needs a LOT more publicity.

tonyedgecombe 7y ago

It would be nice to have something with a permissive license. There are a lot of commercial offerings but the costs make them prohibitive for my projects.

lsllc 7y ago

Go has a number of PDF libraries including GoFPDF which is actually really good and very well rounded. These days you can easily build a "C" interface to a shared library implemented in Go. https://github.com/jung-kurt/gofpdf https://github.com/jung-kurt/gofpdf