4 ms·

Is there something hard about fillable forms on PDF? Why have a PDF viewer at all if it couldn't fill out a form?

foxdev 6y ago
While PDF is an open format on paper, in practice it's as proprietary as any ancient format. Supporting it in full is not trivial.
- core-questions 6y ago
  The real problem here is that, 20+ years on, printing to PDF is still a totally natural and easy-to-understand metaphor for a normal office desktop user; but producing HTML for the browser is still impossible for them. If we simply had print-to-HTML functionality which resulted in a document identical to what you view onscreen while editing, PDF could die the death it deserves. But HTML+CSS somehow manages to suck just as much for common usage, so it persists.
  - foxdev 6y ago
    I wish epub would catch on for more than books. An epub is just HTML and CSS in a zip file, and a large part of the world population has a device than can load it and present it cleanly.
derefr 6y ago
> Is there something hard about fillable forms on PDF? In the sense of a “form” just being lines on paper that you can arbitrarily add some text to — no, that’s easy. Likewise, in the sense of a “form” being some defined input regions that accept your keystrokes and turn them into new text DOM nodes in the PDF itself — easy enough. Though, unlike HTML, there’s no concept of an <input> tag that just has the semantics of accepting keystrokes and turning them into (persisted) input; instead, this all has to be done through scripting [i.e. writing event-handlers, or having some PDF authoring software generate them]; and there are several incompatible scripting languages for PDF that get used, some of which are proprietary with no open specification. But, doing form validation? Or, worse yet, making one of those fancy PDF forms that auto-calculates fields like an Excel spreadsheet? Now you’re getting into the hairy stuff, because IIRC none of the open-standard PDF scripting systems provide these sorts of mechanisms, so these are inherently proprietary things. And when I say “proprietary”, I mean “like old versions of Word or Photoshop, where each version emitted its own in-memory data-structures to disk without formal serialization; and it was the job of authors of future versions to write importers to deserialize whatever format resulted.”
gpvos 6y ago
I don't know about you, but >98% of the PDFs I use are just for reading and don't contain a fillable form. And implementing a PDF viewer is already a major undertaking; adding the form functionality complicates things even more.
- nip 6y ago
  I posted a link (above) to the app I built to solve that problem. The vast majority of form is indeed not « ready » for input, requiring users to go through hoops to fill them. And that work is done again by the next person.
  - gpvos 6y ago
    I wasn't referring to any problem. Again, all those PDFs I wrote about are intended for reading only; no filling in, signing or other form of interaction other than reading letters that form words on a page is involved in any way, and that is entirely fine and how it should be, so both the PDF itself and a PDF reader that has no form-filling functionality would be entirely fit for purpose (notice the word "reader").
    - nip 6y ago
      In that case, all is well indeed. The problem I was referring to, is when one is expected to fill a PDF that was not built to be filled, such as the scan of a paper form.
jahewson 6y ago
Yes! PDF forms are amazingly complex. Text in PDF is very complex and the forms themselves are a kind of templated vector graphics. Multiply this by all the weird and corrupt PDF forms out there which Acrobat support and you have a challenging task.

While PDF is an open format on paper, in practice it's as proprietary as any ancient format. Supporting it in full is not trivial.

core-questions 6y ago
The real problem here is that, 20+ years on, printing to PDF is still a totally natural and easy-to-understand metaphor for a normal office desktop user; but producing HTML for the browser is still impossible for them. If we simply had print-to-HTML functionality which resulted in a document identical to what you view onscreen while editing, PDF could die the death it deserves. But HTML+CSS somehow manages to suck just as much for common usage, so it persists.
- foxdev 6y ago
  I wish epub would catch on for more than books. An epub is just HTML and CSS in a zip file, and a large part of the world population has a device than can load it and present it cleanly.

derefr 6y ago

> Is there something hard about fillable forms on PDF? In the sense of a “form” just being lines on paper that you can arbitrarily add some text to — no, that’s easy. Likewise, in the sense of a “form” being some defined input regions that accept your keystrokes and turn them into new text DOM nodes in the PDF itself — easy enough. Though, unlike HTML, there’s no concept of an <input> tag that just has the semantics of accepting keystrokes and turning them into (persisted) input; instead, this all has to be done through scripting [i.e. writing event-handlers, or having some PDF authoring software generate them]; and there are several incompatible scripting languages for PDF that get used, some of which are proprietary with no open specification. But, doing form validation? Or, worse yet, making one of those fancy PDF forms that auto-calculates fields like an Excel spreadsheet? Now you’re getting into the hairy stuff, because IIRC none of the open-standard PDF scripting systems provide these sorts of mechanisms, so these are inherently proprietary things. And when I say “proprietary”, I mean “like old versions of Word or Photoshop, where each version emitted its own in-memory data-structures to disk without formal serialization; and it was the job of authors of future versions to write importers to deserialize whatever format resulted.”

gpvos 6y ago

I don't know about you, but >98% of the PDFs I use are just for reading and don't contain a fillable form. And implementing a PDF viewer is already a major undertaking; adding the form functionality complicates things even more.

nip 6y ago
I posted a link (above) to the app I built to solve that problem. The vast majority of form is indeed not « ready » for input, requiring users to go through hoops to fill them. And that work is done again by the next person.
- gpvos 6y ago
  I wasn't referring to any problem. Again, all those PDFs I wrote about are intended for reading only; no filling in, signing or other form of interaction other than reading letters that form words on a page is involved in any way, and that is entirely fine and how it should be, so both the PDF itself and a PDF reader that has no form-filling functionality would be entirely fit for purpose (notice the word "reader").
  - nip 6y ago
    In that case, all is well indeed. The problem I was referring to, is when one is expected to fill a PDF that was not built to be filled, such as the scan of a paper form.

jahewson 6y ago

Yes! PDF forms are amazingly complex. Text in PDF is very complex and the forms themselves are a kind of templated vector graphics. Multiply this by all the weird and corrupt PDF forms out there which Acrobat support and you have a challenging task.