First off Happy New Year to you and anyone else reading this.
Thanks, and same back to you.
Sorry if I confused you. I thought I was pretty clear.
I'll share some quotes from your feedback which flummoxed me:
"it's not very useful when you just show a little RPG logic to process the
fields and then call your black box."
"If I had a need for this functionality I would be saying to myself: "WTF
the author left me hanging with this example. I can already do nice looking
RPG to synthesize CGI fields. I want PDF."
"I guess if your intent was general concept that's fine, but show us the
money !!"
"Well a feature complete article on filling a PDF from HTML input should
include..."
In regards to "it's not very useful...", I think that showing a live
example of fill-in-the-blank input paired with PDF output addresses the
question of what the user experience is like, along with showing a design
pattern which could be applied generally. The demo was geared to the
questions raised in the original thread. Add to that a complete HTML form
sample, a complete RPG program, and narrative explanation.
In regards to "synthesize CGI fields", synonyms for "synthesize" include
"artificial", and "fake". What was your intent in that?
In regards to "if your intent was general concept", why would you consider
a live demo application with a nearly complete code sample a general
concept?
In regards to "show us the money!!", I have no idea what that means.
If you're going for a conceptual article then you're done.
Again, synonyms of "conceptual" are "imaginary", "theoretical", "notional".
I believe you've mislabeled the application, the source code, and
explanation behind it.
I agree that the HTML web form to generating PDF docs approach is cool and
it appears you've had success doing the convert pre-formatted HTML to PDF
approach.
I agree with the "cool" comment.
However my previous thread answers get more to the heart of filling out an
existing PDF form template from the web form data or just filling a
fillable PDF template from a background IBM i job with data.
Thanks for that context. I agree that the original thread pertained to
using Adobe Reader as a vehicle for collecting form data. I just think
that's a poor choice.
That's probably closer to what your wife's team and other government,
healthcare and other entities possibly need. Gather data in business
system and automatically fill out existing government PDF forms with no
keying. And then users can edit the final PDF as needed with Acrobat or
other 3rd party PDF reader or editor unless they flatten the PDF which is
the concept of essentially burning the data into the final document.
Okay, if you think that's what they need. I indicated in my previous post
why I believe Adobe Reader to be a poor choice for collecting data.
Marrying a web form with ANY fillable PDF document and capturing the data
once and then filling the pixel perfect government or other form is an
awesome approach and the final PDF output can still be modified if needed
or flattened if permanent
I thought I was the one suggesting a marriage between a web form and a PDF
document. That's why I forked the thread. I thought you were suggesting
learning Java and the iText API to transform an interactive PDF, or
contracting with someone who had the experience.
Your HTML to PDF method does not allow changing the final PDF unless you
possibly use Adobe Pro.
Again, I don't think interactive PDF's are a good way to collect data. So
I wouldn't recommend writing a program and using iText to "fill in" some of
the blanks.
By re-using existing PDF documents as templates for fillable HTML web forms
you've just removed form design for thousands maybe even millions of
existing publicly available, fillable PDF forms. Now that's time savings !!
Good point about reusing existing PDFs. I'd suggest converting them to
images, referencing them as a background object, and overlay it with HTML
inputs.
In case you doubt my experience on the topic of fillable forms and forms
output, I'll add a little reminder.
I don't doubt your experience. Quite to the contrary it is one of the
reasons that I was thrown off by your repeated prodding for me to write a
follow-up article. Given your knowledge experience, why wouldn't you write
"a feature-complete article" for do-it-yer-selfers? Why ask me?
There's nothing wrong with the HTML to PDF approach you advocate. It just
doesn't work for super-complex fillable government forms that require very
specific formatting.
In regards to super-complex and very specific formatting, you can do that
by attaching CSS styling to HTML elements. Absolute positioning and pixel
perfect precision is part of the spec.
Feel free to check out any of my webinar recordings on the topic of output
forms and fillable forms.
I'd like that. Can you provide a link to something which would be relevant
to this thread or the original?
midrange.com
