A PDF can contain scripts, and the scripts could of course set this parameter value just as a script line (executed on document open).
Phoning home was roundly condemned a few years back, so this now triggers a warning message, but can still work.
Connecting to a web service may need special privileges or a copy of Acrobat, not sure on that. You can submit to a server that returns fields which are filled back in, however.
No idea what an RIA is tho'.
The problem is, the script in the PDF has to receive the parameter and act upon it, not set it. There may be 1000 different values for the parameter, and if we had to hard-code the parameter in the PDF, we'd need 1000 separate PDFs, a maintenance nightmare.
"RIA" is Rich Internet Application.
Phoning home in our context is not the same thing as the surreptitious phoning home of malware/adware. This PDF would be distributed on our extranet to users who would be expecting the document to phone home to retrieve the latest data. But the goal is to have a meticulously styled, printable, paginated document with this dynamically supplied information "late-bound" to the document.
For the present, the dynamically supplied data could be injected into static form fields, although in the future it would be great to have the ability to supply textual content that could be injected into placeholders in paragraphs.
The intention behind the phoning home isn't at issue, but you still get the message.
I think you may be complicating things unnecessarily. Why not use a server process to make the finished document, fully formatted? (You can't use Acrobat on the server, but there are methods).
Or, simply fill the fields before delivering rather than go through add token - open - send token - get fields?
I am not aware of server processes that can generate a precisely styled PDF, replacing placeholders with values extracted from a database. But I'd like to know of some good ones if you have a name or two? Can they start with a pre-existing PDF and use it as the basis for the generated PDF?
What is involved in "filling the fields before delivering"? How can we programmatically inject data into the PDF?
Let's look at what you want to do by way of customising.
Simplest is form fields.
Put text, in a predefined font, into fields at predefined locations on the page.
Normally the user could fill in and change the fields but you can have them read only.
The fields would be added "on top of" a pre-existing fomatted PDF, which can also have such other interactivity as Acrobat offers.
Is that sufficient?
Adding fields "on top of" a pre-existing formatted PDF sounds promising. Can this be done programmatically? Can a program on the server read the PDF and inject those fields? What I'm not clear on is how this can be done "unattended". Could we write a program in C# that runs up on the web-server and talks to an Acrobat API, and thereby fill in the fields on-the-fly immediately prior to the user's downloading it?
I'm assuming the PDF is static and the fields would be added interactively. Then the server product for filling them, Adobe's offering, is called Adobe LiveCycle Forms. Take a look at that (note the full name to avoid confusion with many, many similarly named forms and unless or until you know more absolutely avoid Adobe LiveCycle Designer. At least I think that Adobe LiveCycle Forms is the thing. It has a server Java API. No Acrobat API is involved, Acrobat is client end only.
Thanks, I will look into it.