Live data from Hacker News

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

github.com

101–110 of 126 posts

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

#101
post #99

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?

Not OP. It seems they're files which display different contents depending on the program you open them in.

Here's a CCC talk on it: https://media.ccc.de/v/MRMCD2014_-_6008_-_en_-_grossbaustell...

And the slies from the talk: https://www.slideshare.net/ange4771/schizophrenic-files-v2

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

#102
post #100

Earlier quoted context omitted.

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?

PDF was defined way back before Unicode was ever a thing. It is natively an 8-bit character-set format for text handling. The way it gets around this limit of only 256 characters available is because it also allows defining custom byte to character glyph mappings (think both ASCII and EBCDIC encoding in different parts of the same document). To typeset a glyph that is not in the current in use 256 character sub-set mapping you switch to a different custom byte value to character glyph mapping to typeset that other character.

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

#103
post #102
post #100

Earlier quoted context omitted.

> lack of proper Unicode What do you mean?

PDF was defined way back before Unicode was ever a thing. It is natively an 8-bit character-set format for text handling. The way it gets around this limit of only 256 characters available is because it also allows defining custom byte to character glyph mappings (think both ASCII and EBCDIC encoding in different parts of the same document). To typeset a glyph that is not in the current in use 256 character sub-set m…

> PDF was defined way back before Unicode was ever a thing.

Unicode 1.0 was released in 1991.

PDF 1.0 was released in 1993.

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

#104
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

> the most reliable way of generating PDFs

See pandoc: https://pandoc.org/

And a variety of intermediate or input text formats, where you can pick your preferred poison whether for book publishing, research papers, math papers, technical documentation, slides, etc.

Including the author's own djot: https://github.com/jgm/djot

EDIT:

Sibling reply suggests latex. OK, but then you're also learning latex.

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

#105

Is there a list of open source PDF libraries for various languages? And related: the best tools to generate PDFs from HTML.

The best generator is Prince XML but it can be expensive.

Seconded. I've recreated a corporate CI with it and had a great time. To have a single compile target is a blessing.

Also: the only software I know of written in Mercury.

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

#106

I’ve done a bit of PDF wrangling in Python, so figured I’d describe the lay of the land. PyPDF [1] is great for reading and writing PDF files, especially dealing with pages, but it’s not great for generating paths, shapes, graphics, etc. However, reportlab [2] has a great API for generating those things, but is lacking in the file IO and page management department. But the content streams it generates can be plugged…

QPDF is a good C++ library for "content preserving" PDF transformations, and is used by the Python PikePDF library.

I've found out the hard way that boxing/unboxing of PDF primitives to Python is _really_ expensive, so that my workflow has been counter-intuitively quite a lot slower than with PyPDF2.

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

#107
post #105

Earlier quoted context omitted.

The best generator is Prince XML but it can be expensive.

Seconded. I've recreated a corporate CI with it and had a great time. To have a single compile target is a blessing. Also: the only software I know of written in Mercury.

Mercury and Rust (according to Wikipedia).

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

#108
post #50

Good luck, I once started to scratch the same itch to learn this file format, several years later I think I got about 30% of the way through! More open source PDF code is good. If you can find a version of iText RUPS application from somewhere on the internet it's a useful tool for viewing the syntax / structure.

> find a version of iText RUPS application from somewhere on the internet You mean this, right? https://github.com/itext/i7j-rups#readme

Yes, that's the one. I found a compiled version somewhere because I was too lazy to install/learn Maven/Java stuff in order to build from source.

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

#110

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…

"The ALAN Parsers Project"

Bravo! Best wordplay I've reaed today.

Post reply on HN