[Scribus] Creating PDF forms whose data can be saved with acrobat reader

[Craig Ringer]

Gregory Pittman wrote:
> This is of interest, and worth figuring out. It's not clear to me that 
> this is entirely in Adobe's interest to restrict this usage -- 
> encourages someone to develop a more open forms format.
>   
Probably not. What's likely to happen in the long run is that as other 
PDF readers are enhanced they'll gain full forms support, like Adobe 
Reader but without requiring the same unlocking signature. Some of the 
Linux-based ones are already moving in that direction - and with KDE 4 
the KDE PDF viewer is likely to be ported to Mac OS X and Windows too. 
So it's probably not going to be too long before users with non-Adobe 
PDF readers can handle forms quite well.

Adobe's advantage is their user base. Their app is bundled on driver and 
app installer CDs, pushed by websites, etc. An alternative form option 
would have to provide the same sort of utility and resulting ubiquity 
that Adobe Reader has to be really interesting. That's why they can sell 
the ability to unlock extra form features in Reader to people - because 
it's *already* on a user's machine. Alternative open forms formats would 
not have that, and wouldn't be any better than telling the user to 
download some other PDF utility.

Web forms are of course the main alternative, and just fine almost all 
the time. I don't see saved PDF forms as hugely interesting except when 
combined with digital signatures and widely accepted certificate 
infrastructure, as is found within governments and large corporations, 
where archival and attestation is very important. Unsurprisingly, this 
is the market that the Adobe PDF enhancements stuff is targeted at.

I'm not really sure why people bother with this stuff for use with the 
general public. If they're going to fill the form out, save it, and 
email/upload it back to you without using a digital signature why not 
use a web form? They can already fill it out and print it with Reader 
without any special enabling, so that doesn't justify it. Reader also 
supports web submit (with JavaScript and HTTP POST) from a form without 
any sort of feature enabling signature, and that's the only other reason 
I can think of to use it. The latter case is just an alternative user 
interface for a web form anyway.
> I've always felt that this is one of the big ways that proprietary 
> formats are very wrong -- I take *my* data, *my* creative input, and it 
> gets held hostage in a format I do not have complete rights over -- very 
> very wrong.
>   
It's a bit different in this case, in that PDF *is* an open format, it's 
fully documented, and you can do basically whatever you want with it. 
You can include your own enabling signature, for example. The only 
difference is that Adobe's free Reader product (hardly the only PDF 
reader in town) chooses not to honour feature enabling signatures from 
people who're not authorized by Adobe.

What's happening here is a little different to the usual "proprietary 
extensions" stuff that many companies like to get up to. Adobe has fully 
documented the reader enabling mechanism, the only thing missing is the 
private key required to use it. It's a backwards way of selling licenses 
to Adobe Reader, where the license sold is to the ability to enable 
extra features on Reader on a user's machine rather than the direct 
rights to use Reader, and is paid for by the form creator rather than 
the end user. It's not, in my view, hugely different from requiring a 
license for products like Acrobat Pro and Acrobat Server, which operate 
on PDF but are not free. It's not restricting what other PDF viewer apps 
can do, nor what PDF creators can do to interact with other viewers and 
it doesn't hide any data away in non-standard ways.

In a way I guess it *is* getting around the open standard nature of PDF 
to provide enhanced features for Adobe products talking to Adobe 
products. I don't much like it for that reason, but I do see it as very 
different from using undocumented extensions to break compatibility in a 
format or similar nastiness. There are no secret APIs or undocumented 
binary blobs here.

--
Craig Ringer