In my opinion, one should _always_ try to get changes/fixes/patches applied upstream. Even if the still need some discussion/tuning. In the long run everyone benefits. Think of 1000 people maintaining their own fork of the Linux kernel.
Filling in PDF forms with Python (2018)
11–20 of 20 posts
Re: Filling in PDF forms with Python (2018)
#12Anyone familiar with the history of how PDFs became such a widespread format in the first place? I get that it looks nice but not being able to edit it by default just seems weird to me.
The “read only” nature of PDFs is a feature, not a bug. The idea being that once you distribute the PDF, it can’t be changed, and thus has more “truth” than something editable would. Even now PDF is considered an acceptable format for legal documents where Word docx is not. Of course this is completely false safety given that many programs can edit PDFs.
Including Word nowadays!
Re: Filling in PDF forms with Python (2018)
#13Anyone familiar with the history of how PDFs became such a widespread format in the first place? I get that it looks nice but not being able to edit it by default just seems weird to me.
The “read only” nature of PDFs is a feature, not a bug. The idea being that once you distribute the PDF, it can’t be changed, and thus has more “truth” than something editable would. Even now PDF is considered an acceptable format for legal documents where Word docx is not. Of course this is completely false safety given that many programs can edit PDFs.
> Of course this is completely false safety given that many programs can edit PDFs.
But can you edit a properly signed[1] PDF without breaking it? From an integrity perspective, that's what matters; otherwise, it's just inherently more portable until non-repudiation becomes relevant.
[1] As in not SHA-1: https://shattered.io/
Re: Filling in PDF forms with Python (2018)
#14Anyone familiar with the history of how PDFs became such a widespread format in the first place? I get that it looks nice but not being able to edit it by default just seems weird to me.
If you think that's crazy, wait until you hear about HTML!
You laugh, but surely there is a case for standard of static html+css these days to do 95% of what pdf does.
I don't think anyone is motivated enough to make that standard, however.
Re: Filling in PDF forms with Python (2018)
#15I had to solve this problem a few years ago. My solution was as follows:
1. Convert PDF -> multiple individual SVG files. (I probably used Cairo)
2. Use Inkscape to set your fields and name them like Django template variables.
3. Store these prepared SVGs in the file system of your app.
4. Call them when needed and fill them in with the Django Template rendering engine.
4a. Works with including images too if you convert them to base64 encoded PNG, then insert them into the SVG.
5. Convert individual SVGs -> individual PDFs. (Cairo)
6. Merge individual PDFs into a single combined PDF. (Cairo)
7. Deliver finished merged PDF.
After the initial step of preparing your SVG, which can take a bit of time to get right, it only takes about 2-3s to produce a fully compiled PDF and gives you all of the necessary functionality out of them - sans all of these chaotic intervening libraries.
I can't tell you how many months it took me to figure that out. It was a while though. When the system was operational, we were sending 10,000 multipage PDFs per day on a single Django instance on a T2 medium AWS instance.
Re: Filling in PDF forms with Python (2018)
#16Anyone familiar with the history of how PDFs became such a widespread format in the first place? I get that it looks nice but not being able to edit it by default just seems weird to me.
The “read only” nature of PDFs is a feature, not a bug. The idea being that once you distribute the PDF, it can’t be changed, and thus has more “truth” than something editable would. Even now PDF is considered an acceptable format for legal documents where Word docx is not. Of course this is completely false safety given that many programs can edit PDFs.
> Of course this is completely false safety given that many programs can edit PDFs.
Well, unless you sign the PDF. Even more, you can sign each edit separately, so you can do things like add content and signatures and still verify who added what. Meaning: one party can create PDF with forms, sign it, then the party filling out the form can sign their own changes for authentication.
And let's not forget the fact that PDF renders correctly on pretty much any machine you put it on - this is incredibly important.
Re: Filling in PDF forms with Python (2018)
#17Anyone familiar with the history of how PDFs became such a widespread format in the first place? I get that it looks nice but not being able to edit it by default just seems weird to me.
PDF is a high-quality vector format that displays the same on every device, can be produced by many different applications but use the same viewer, and has a public specification that's an ISO standard. There's very little competition. Compressed PostScript is clunky, slow, and still big, XPS was too late, DJVU is primarily for scans. Things like Word or HTML display differently on different devices, Word and many other formats are or were proprietary.
Re: Filling in PDF forms with Python (2018)
#18Anyone familiar with the history of how PDFs became such a widespread format in the first place? I get that it looks nice but not being able to edit it by default just seems weird to me.
PDF is a high-quality vector format that displays the same on every device, can be produced by many different applications but use the same viewer, and has a public specification that's an ISO standard. There's very little competition. Compressed PostScript is clunky, slow, and still big, XPS was too late, DJVU is primarily for scans. Things like Word or HTML display differently on different devices, Word and many ot…
What about [DVI](https://en.wikipedia.org/wiki/Device_independent_file_format)?
Re: Filling in PDF forms with Python (2018)
#19Earlier quoted context omitted.
PDF is a high-quality vector format that displays the same on every device, can be produced by many different applications but use the same viewer, and has a public specification that's an ISO standard. There's very little competition. Compressed PostScript is clunky, slow, and still big, XPS was too late, DJVU is primarily for scans. Things like Word or HTML display differently on different devices, Word and many ot…
What about [DVI]( https://en.wikipedia.org/wiki/Device_independent_file_format )?
Only really used for TeX-related things. Not general purpose as it can't embed fonts, and graphics is usually by embedding PostScript I think.
Re: Filling in PDF forms with Python (2018)
#20I had a similar need at a company I worked for. My solution was actually quite similar to the author's #1 with the major exception being that I used ODG for LibreOffice Draw which mostly solves the author's two main complaints here. Background images can be high quality and placing your text is as easy as clicking where you want to place your text box. The only other major difference is that I didn't interact with UN…
I've had great success with this library: