Earlier quoted context omitted.
Yes, maybe generally; but let’s talk about the specific case here — filling of complex PDF forms. When a PDF that has interactive form fields, calculated auto-populated fields, fields that are enabled/disabled according to the inputs of other fields, etc. — the organization that created it (usually government or education) usually does that because they want you to fill it out using a PDF viewer; save it (which will…
> 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 edi…
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_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.