Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I am building a new Python library to read/write PDF files

github.com

Post reply on HN
Print view View original

91–100 of 126 posts

Re: Show HN: I am building a new Python library to read/write PDF files

#91

Post by jjgreen »

manv1 wrote: post #64
notacop31337 wrote: post #9

Earlier quoted context omitted.

My understanding is that this is largely because you're fighting an adversarial format provider in Adobe, I've read a few papers and journal entries on file format polyglotting, with some focus on PDF and approaches are constantly shifting in nature due to Adobe mooting pathways to success, I think it's partly for security and also IMO partly for obscurity as PDF is a horrific format in all reality except for human v…

PDF is a subset of Postscript, which is a full-blown programming language disguised as a page description language. People who think of the format as "adversarial" are wrong. Adobe never gave a shit about being adversarial in that sense. The problem is that PDF is not a file format, it's a defined subset of a programming language (PostScript) used for portable rendering with fidelity. It's portable, in the sense that…

Postfix is fine, you get used to it fairly quickly. But when you've finished and want to go the the toilet, you walk there backwards.

Re: Show HN: I am building a new Python library to read/write PDF files

#92

Post by mkl »

Eatcats wrote: post #90

Thank you, it is much needed, right now the most reliable way of generating PDF's I used not so long time ago is - create DOCX with content and some template variable strings, like {{}} - unpack document and get into text, replace text - use DOCX->PDF linux tool to generate document. Maybe this will be the good solution

Latex seems way better than either to me (but then, I know Latex). Certainly Latex makes it much easier to get consistency and precision. For your use-case, generate Latex code from a template using Python or whatever, substituting in what you need, then compile the Latex into a PDF. If you need graphical elements or precise layout control, use the Latex package TikZ.

If what you need is very simple (e.g. no word wrapping, same number of variable strings in the same positions), even manipulating the code of a template PDF directly is not too hard. This library would help with that.

Re: Show HN: I am building a new Python library to read/write PDF files

#93

Post by mkl »

nomel wrote: post #82
larsonnn wrote: post #76

This reminds me back in the day where we got some properties and thought, PDF is a defined file format. Every pdf has this values… We were so naiv and didn’t know.

I asked the vendor if they had a 3d model viewer, so we could inspect a part they were making. He sent me a PDF. Full pan, tilt, zoom, and hideable pieces. I don't know what kind of witchcraft was involved, but I suspect OP will come out of this cursed by its unholy nature.

Most PDF viewers don't support the 3D models feature, and just show a static image (literally an embedded image; they don't look at the 3D data at all). I've used it to make 3D diagrams for multivariable calculus, done with Asymptote (https://asymptote.sourceforge.io/).

Re: Show HN: I am building a new Python library to read/write PDF files

#94

Post by jonnycomputer »

fgeiger wrote: post #80
mdaniel wrote: post #6

I never knew about the J number suffix in python: https://docs.python.org/3/reference/lexical_analysis.html#im... which it would appear is used to represent references: https://github.com/desgeeko/pdfsyntax/blob/main/tests/test_p... I wish you good luck, this file format has tripped up many, many a developer. It blew up on a pdf I had lying around: ValueError: could not convert string to float: b'5.0.0' 104 0 obj > e…

The PDF format is diverse enough for such a new project to still have plenty of incompatibilities. If you wanted to find many of them quickly, you might want to have a look at the documents used as test cases in other projects, such as pdf.js: https://github.com/mozilla/pdf.js/tree/master/test/pdfs

Valuable practical, actionable advice

Re: Show HN: I am building a new Python library to read/write PDF files

#95

Post by contentboot »

chazeon wrote: post #17

On the field of PDF parsing, I think the most interesting project I encountered is pdfquery[1], where the PDF is parsed as a XML tree and you can use XPath to query it. You might encounter rough edges when put it into production work but the idea is like “how come i never thought of this” because PDF has some tree like structure and should be a straightforward solution. [1]: https://github.com/jcushman/pdfquery

This is great, thank you for posting it.

Re: Show HN: I am building a new Python library to read/write PDF files

#96

Post by IshKebab »

nomel wrote: post #82
larsonnn wrote: post #76

This reminds me back in the day where we got some properties and thought, PDF is a defined file format. Every pdf has this values… We were so naiv and didn’t know.

I asked the vendor if they had a 3d model viewer, so we could inspect a part they were making. He sent me a PDF. Full pan, tilt, zoom, and hideable pieces. I don't know what kind of witchcraft was involved, but I suspect OP will come out of this cursed by its unholy nature.

PDF has a load of advanced features - 3D models, video, Flash. Basically only Adobe supports any of it though.

I wish more readers supported video but IIRC the standard doesn't actually support a normal modern format.

Re: Show HN: I am building a new Python library to read/write PDF files

#97

Post by dagw »

jl6 wrote: post #73

Good to see work in the PDF space. It’s still one of the most important formats. I would love to see more time invested in tools that can create PDF/A documents, which I believe to be the sane subset of PDF.

A PDF generator library that only generated guarenteed PDF/A compliant PDFs would actually be really good selling point for a new PDF library.

Re: Show HN: I am building a new Python library to read/write PDF files

#98

Post by ESultanik »

Be careful with PDF! There are many ambiguities in the specification that are implemented differently between parsers, as well as implicitly accepted malformations that almost all parsers will silently accept without warning. It is very easy to accidentally produce so-called file format schizophrenia: When the same file is rendered differently between two parsers. For example, with PDF, what if you have a PDF object stream that has a length that doesn't agree with the position of its `endstream` token? What if you have a PDF dictionary with duplicate keys? Do you use the value of the first key or the second? What if you have two, valid PDFs concatenated one after the other? Do you render the first or the second? What if an object in the XREF table has an incorrect offset?

Shameless plug: I am one of the maintainers of PolyFile, which, among other things, can produce an interactive HTML hex editor with an annotated syntax tree for dozens of filetypes, including PDF. For PDF, it uses a dynamically instrumented version of the PDFminer parser. It sounds like it might satisfy your use case.

https://github.com/trailofbits/polyfile

Re: Show HN: I am building a new Python library to read/write PDF files

#99

Post by sdgluck »

ESultanik wrote: post #98

Be careful with PDF! There are many ambiguities in the specification that are implemented differently between parsers, as well as implicitly accepted malformations that almost all parsers will silently accept without warning. It is very easy to accidentally produce so-called file format schizophrenia: When the same file is rendered differently between two parsers. For example, with PDF, what if you have a PDF object…

In the README for that repository it mentions "schizophrenic files". What is a schizophrenic file, out of interest?

Re: Show HN: I am building a new Python library to read/write PDF files

#100

Post by jwilk »

jahewson wrote: post #19
jeremynixon wrote: post #11

Why is the state of the art in PDF parsing SO BAD? This is an incredibly common and important problem. Tika and fitz have very poor results. What is the reason that this is still so backwards?

Despite the thousands of pages of ISO 32000, the reality is that the format is not defined. Acrobat tolerates unfathomably malformed PDF files generated by old software that predates the opening-up of the standard when people were reverse-engineering it. There’s always some utterly insane file that Acrobat opens just fine and now you get to play the game of figuring out how Acrobat repaired it. Plus all the fun of th…

> lack of proper Unicode

What do you mean?

Post reply on HN