4 ms·

> In fact, many such “fillable” PDFs start off in a state with many of their form-fields disabled and voided, such that printing them out in that state would re

> In fact, many such “fillable” PDFs start off in a state with many of their form-fields disabled and voided, such that printing them out in that state would result in a form you can’t really write on! I have never seen this. Do you have an example? Every use if fillable PDFs I have encountered is a use case where submitting a handwritten form is still an option. > The only benefit a client gets is the ability to edit and save the form offline (but that can be done in a browser, too, with local storage); and furthermore, the ability to treat the resulting filled form as a file, moving it around before you submit it. I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy. > But the cases where you need that are very niche, compared to the cases where you can just direct employees to your Intranet portal. This is not a trivial need; most forms sent as fillable PDFs need to or should be retained for some period after submission. Also, I don't know what "employees" and "Intranet" has to do with anything. You are also missing the use case where a form legally requires a live signature from one or more parties and need to be printed, even if just to scan and return. I recently had to do this for some insurance paperwork.

Isthatablackgsd 6y ago
> You are also missing the use case where a form legally requires a live signature from one or more parties and need to be printed, even if just to scan and return. I recently had to do this for some insurance paperwork. My company have to do this for one state government. They required the signature to be written black inked. It is PITA to do since we all have digital signature set up. But nope, this state government required the written signature.
andrewshadura 6y ago
The Canadian visa application form is an example.
derefr 6y ago
> I have never seen this. Do you have an example? I don't have one on-hand, no. But I've certainly had to fill them out in the past. IIRC an especially-bad one came in the form [heh] of a student-loan application for the college I attended. It was essentially a Hypercard stack in the guise of a PDF. Here are some early Adobe marketing materials (as a PDF, because of course it is) talking about the advantages of "eForm Solutions": https://planetpdf.com/planetpdf/pdfs/pdf2k/02E/ldefurio_pdfforms.pdf https://planetpdf.com/planetpdf/pdfs/pdf2k/02E/ldefurio_pdff... It sounds like every PDF form you've ever dealt with is what Adobe, in this brochure, calls a "Type 1: Print and Fill" or "Type 2: Fill and Print" form. But Type 3 and Type 4 forms do exist in the wild! (They're not often created any more; most of the ones that exist now are from around a decade or two ago, when Adobe was really pushing this idea.) Creating such forms was basically the point of Acrobat as a software product. When PDF viewers (e.g. Apple Preview) say they don't support "PDF forms", they're not talking about Type 2 forms. They usually support those just fine. They're talking about Type 3 and Type 4 forms. And more specifically, the ones that use Adobe's proprietary AcroForms data-embedding system, rather than the open-standard XFA data-embedding system. (I could swear I saw an HN post about the horrors of AcroForms once, but I can't find it now.) > I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy. To be clear, that was what I meant by the second qualifier, "as a file." Browsers support persisting the state of the form. Just, not as a file. They persist the state internally, when the form's author does the client-side Javascript work to enable that. For the use-case where the user wants to stop filling out the form for now (e.g. because they don't have some required information on-hand), and then come back to it to finish it later, in-browser persistence works perfectly well. Even cleaner, though, is just building a web-form as a wizard, where fields are submitted one-at-a-time, and you can also freely navigate to previously-filled "steps" to change your answers. That doesn't even require JavaScript; just pure 90s HTML-generated-on-the-backend. Most government sites that thought PDF eForms were a good idea, are now falling back to this approach. > Also, I don't know what "employees" and "Intranet" has to do with anything. Secure installations. The main use-case for fillable PDFs (as can be seen in Adobe's marketing brochure, where "government" is the core client) is a case where public or cloud solutions just aren't tenable, i.e. in secure government/military/etc. installations, where the workstations are air-gapped from the public Internet. In such a case, PDF forms can still be sent around via a local non-Internet-routable email server, for the workers there to fill in. Today, this need can be served just as well by setting up a non-Internet-routable web portal for those same workers to use. But back in the 90s and 00s, "Intranet web portals" were a fancy thing only the most forward of IT bigcorps had on offer. They had Intranets, for sure, but they weren't hosting web-apps on them. So, what did they do instead? Well, Adobe had two main competitors in the "eForm" market: • Lotus Notes form documents, connecting to a Lotus Domino database server; • Microsoft Excel sheets that use VBA to data-bind to an accessible Microsoft Access database file sitting on an SMB network share. None of these "forms" were hand-submittable. They're all little self-contained interactive applications, that happen to look like forms. AcroForms did have the fancy property, though, that the AcroForms application-PDF could generate or export a bog-standard output-PDF representing the filled form. But that's not actually a modified copy of the source PDF. That's the PDF using scripting to generate you another PDF, from scratch. ------ To be clear, I agree with all the stuff you're talking about; those are all valid use-cases for "PDFs" (i.e. encapsulated PostScript containers.) But they're not what I mean by "PDF forms." I mean the Type 3/4 forms referred to above. There's no reason, in the modern era, that one would implement one of these Type 3/4 "eForm solutions", instead of just putting up a webpage. If you need an e-signature at the end, have them fill out the web form, then generate a raw PostScript PDF representing their inputs, and let them sign it by dropping a signature vector image on the dotted line in any standard PDF viewer.

Isthatablackgsd 6y ago

> You are also missing the use case where a form legally requires a live signature from one or more parties and need to be printed, even if just to scan and return. I recently had to do this for some insurance paperwork. My company have to do this for one state government. They required the signature to be written black inked. It is PITA to do since we all have digital signature set up. But nope, this state government required the written signature.

andrewshadura 6y ago

The Canadian visa application form is an example.

derefr 6y ago

> I have never seen this. Do you have an example? I don't have one on-hand, no. But I've certainly had to fill them out in the past. IIRC an especially-bad one came in the form [heh] of a student-loan application for the college I attended. It was essentially a Hypercard stack in the guise of a PDF. Here are some early Adobe marketing materials (as a PDF, because of course it is) talking about the advantages of "eForm Solutions": https://planetpdf.com/planetpdf/pdfs/pdf2k/02E/ldefurio_pdfforms.pdf https://planetpdf.com/planetpdf/pdfs/pdf2k/02E/ldefurio_pdff... It sounds like every PDF form you've ever dealt with is what Adobe, in this brochure, calls a "Type 1: Print and Fill" or "Type 2: Fill and Print" form. But Type 3 and Type 4 forms do exist in the wild! (They're not often created any more; most of the ones that exist now are from around a decade or two ago, when Adobe was really pushing this idea.) Creating such forms was basically the point of Acrobat as a software product. When PDF viewers (e.g. Apple Preview) say they don't support "PDF forms", they're not talking about Type 2 forms. They usually support those just fine. They're talking about Type 3 and Type 4 forms. And more specifically, the ones that use Adobe's proprietary AcroForms data-embedding system, rather than the open-standard XFA data-embedding system. (I could swear I saw an HN post about the horrors of AcroForms once, but I can't find it now.) > I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy. To be clear, that was what I meant by the second qualifier, "as a file." Browsers support persisting the state of the form. Just, not as a file. They persist the state internally, when the form's author does the client-side Javascript work to enable that. For the use-case where the user wants to stop filling out the form for now (e.g. because they don't have some required information on-hand), and then come back to it to finish it later, in-browser persistence works perfectly well. Even cleaner, though, is just building a web-form as a wizard, where fields are submitted one-at-a-time, and you can also freely navigate to previously-filled "steps" to change your answers. That doesn't even require JavaScript; just pure 90s HTML-generated-on-the-backend. Most government sites that thought PDF eForms were a good idea, are now falling back to this approach. > Also, I don't know what "employees" and "Intranet" has to do with anything. Secure installations. The main use-case for fillable PDFs (as can be seen in Adobe's marketing brochure, where "government" is the core client) is a case where public or cloud solutions just aren't tenable, i.e. in secure government/military/etc. installations, where the workstations are air-gapped from the public Internet. In such a case, PDF forms can still be sent around via a local non-Internet-routable email server, for the workers there to fill in. Today, this need can be served just as well by setting up a non-Internet-routable web portal for those same workers to use. But back in the 90s and 00s, "Intranet web portals" were a fancy thing only the most forward of IT bigcorps had on offer. They had Intranets, for sure, but they weren't hosting web-apps on them. So, what did they do instead? Well, Adobe had two main competitors in the "eForm" market: • Lotus Notes form documents, connecting to a Lotus Domino database server; • Microsoft Excel sheets that use VBA to data-bind to an accessible Microsoft Access database file sitting on an SMB network share. None of these "forms" were hand-submittable. They're all little self-contained interactive applications, that happen to look like forms. AcroForms did have the fancy property, though, that the AcroForms application-PDF could generate or export a bog-standard output-PDF representing the filled form. But that's not actually a modified copy of the source PDF. That's the PDF using scripting to generate you another PDF, from scratch. ------ To be clear, I agree with all the stuff you're talking about; those are all valid use-cases for "PDFs" (i.e. encapsulated PostScript containers.) But they're not what I mean by "PDF forms." I mean the Type 3/4 forms referred to above. There's no reason, in the modern era, that one would implement one of these Type 3/4 "eForm solutions", instead of just putting up a webpage. If you need an e-signature at the end, have them fill out the web form, then generate a raw PostScript PDF representing their inputs, and let them sign it by dropping a signature vector image on the dotted line in any standard PDF viewer.