3 ms·

1. A webpage form requires a server to be up and running, which requires an IT person to manage it, separate from the dept making the form. PDF forms can be cre

1. A webpage form requires a server to be up and running, which requires an IT person to manage it, separate from the dept making the form. PDF forms can be created by a person given the right tools (I think Word does it) 2. IT person + webserver costs have to included in the budget somewhere. Which can be a big problem. 3. The webpage form can fail, and the support for it has to be provided by the IT dept. If the PDF form fails, dept can handle it on its own, and will often accept a filled+scanned print out of the PDF form. 4. Adding to the point above, PDF forms degrade gracefully, If they don't work, or internet doesn't work, or someone is on holiday, you can still print, fill and hand them in person. Webpages can degrade catastrophically where you whole dept grinds to halt while the IT person tries to fix the problem.

derefr 6y ago
Re: all four of your points — see my sibling post. I'm not talking about encapsulated-PostScript "Print and Fill" forms (which do certainly degrade gracefully), or even open-standard PDF "Fill and Print" forms (which degrade gracefully if you don't set them up with a bad default state where there's big "N/A" text over all the disabled fields until you fill in other fields.) Instead, I'm talking about the PDFs you can basically only load in Acrobat (though, other PDF viewers do try to render them, to varying success) that actually do data-binding to some remote database; do XHRs to submit the form data on success; do "online" onBlur-XHR-esque field validation; generate new output PDFs using scripting, from scratch when you ask them to save/print; etc. These are applications, not documents. You can't print them. You just use Acrobat as a glorified application host to fill and submit them. (You can press Ctrl+P to get Acrobat to request to the loaded PDF application that it perform some scripted action to generate a print output. This may or may not do anything, depending on how the PDF was created. It usually just pops a "Printing is not implemented for this form" box. It certainly won't work in non-Acrobat PDF viewers.) When other PDF viewers say they don't support "fillable PDF eForms", these are the things they're talking about. They usually support "Fill and Print" forms just fine, because "Fill and Print" forms are a somewhat-sane format, rather than being a competitor to Lotus Notes.
- abdullahkhalids 6y ago
  I understand better what you are saying. I don't think I have ever seen any PDF forms that require an internet connection. The Canadian Visa application forms have inbuilt validation code, that checks the form, and once you upload it, I believe data is extracted into a database. The benefit of these forms is that the validated form that you submit online is actually printable. Which means that what you see on your screen/paper is pixel by pixel identical to what Canada receives, and therefore _legally_, there is no confusion about what was communicated between Canada and the candidate. Webforms are not as strongly accepted as such by courts. Because they have to be manipulated further before being printed. I have read a bunch of your replies, and you are thinking of all the technical reasons why webforms are better than PDF (you are right in that), but PDFs have legal and operational and budgetary advantages, that are more relevant to various organizations.

derefr 6y ago

Re: all four of your points — see my sibling post. I'm not talking about encapsulated-PostScript "Print and Fill" forms (which do certainly degrade gracefully), or even open-standard PDF "Fill and Print" forms (which degrade gracefully if you don't set them up with a bad default state where there's big "N/A" text over all the disabled fields until you fill in other fields.) Instead, I'm talking about the PDFs you can basically only load in Acrobat (though, other PDF viewers do try to render them, to varying success) that actually do data-binding to some remote database; do XHRs to submit the form data on success; do "online" onBlur-XHR-esque field validation; generate new output PDFs using scripting, from scratch when you ask them to save/print; etc. These are applications, not documents. You can't print them. You just use Acrobat as a glorified application host to fill and submit them. (You can press Ctrl+P to get Acrobat to request to the loaded PDF application that it perform some scripted action to generate a print output. This may or may not do anything, depending on how the PDF was created. It usually just pops a "Printing is not implemented for this form" box. It certainly won't work in non-Acrobat PDF viewers.) When other PDF viewers say they don't support "fillable PDF eForms", these are the things they're talking about. They usually support "Fill and Print" forms just fine, because "Fill and Print" forms are a somewhat-sane format, rather than being a competitor to Lotus Notes.

abdullahkhalids 6y ago
I understand better what you are saying. I don't think I have ever seen any PDF forms that require an internet connection. The Canadian Visa application forms have inbuilt validation code, that checks the form, and once you upload it, I believe data is extracted into a database. The benefit of these forms is that the validated form that you submit online is actually printable. Which means that what you see on your screen/paper is pixel by pixel identical to what Canada receives, and therefore _legally_, there is no confusion about what was communicated between Canada and the candidate. Webforms are not as strongly accepted as such by courts. Because they have to be manipulated further before being printed. I have read a bunch of your replies, and you are thinking of all the technical reasons why webforms are better than PDF (you are right in that), but PDFs have legal and operational and budgetary advantages, that are more relevant to various organizations.