Investigating for bug 121900 I was reading the PDF reference manuals, and I couldn't find anything about such a feature:

http://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf (1.4)

http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_archives/PDFReference15_v5.pdf (1.5)

For 1.6 I didn't find an Adobe link, so search yourself.

http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf (latest, 1.7)

Searching on the web, all the explanations I've found say that you have to open the PDF file in Adobe Pro, enable some feature with this pro-version, and then the PDF file can be opened with the free version and be saved.



@Andre: I tested with Okular (KDE) and Evince. They don't allow to save, as in save-and-overwrite-the-current file; they offer a "Save as". For what I've read, it seems that Adobe offers a "Save", overwriting the file.

I assume the situation is the same as in bug 73696 and this is some implementation detail of Adobe, not part of any specification.

(In reply to comment #1)
> @Andre: I tested with Okular (KDE) and Evince. They don't allow to save, as
> in save-and-overwrite-the-current file; they offer a "Save as". For what
> I've read, it seems that Adobe offers a "Save", overwriting the file.

Dummy me: reading your quote, "you can also choose File > *Save As* to *rename*"
Anyway, this feature is not documented.

If someone has a PRO version of Adobe, s/he can enable "enabled the local save capability on the form", save the PDF, and compare it to see what is Adobe adding (PDF files are easy to read in a plain text editor; vim even highlights the syntax). That said, even if someone discovers the secret, should we support some strange undocumented feature?

Created attachment 80495 [details]
saved from OpenOffice 3.4.1

If this can be of any help, I'm attaching a PDF file originated with OpenOffice and then "converted" in Adobe Acrobat 8 Professional by the progetto-it list volunteers by enabling rights. Maybe it can be reverse-engineered to check what changed and then look if it is an officially supported feature in the documentation.

I'm attaching:
- i121782-disabled.pdf (from OpenOffice 3.4.1)
- i121782-enabled.pdf (opened in Acrobat and saved by enabling access rights)

Created attachment 80496 [details]
Saved from Acrobat

It looks like "Adobe Acrobat 8 Professional" completely "recoded" the original PDF as saved by OpenOffice, as even the PDF version doesn't match the original (file sizes and contents differ by leaps and bounds):

i121782-disabled.pdf
%PDF-1.4

i121782-enabled.pdf
%PDF-1.6^M%âãÏÓ^M

The approach to try would be to create the simplest possible form (using OpenOffice, for example), and save it. Open from "Adobe Acrobat 8 Professional", as save it as-is, and this would be the "benchmark PDF".

Open this file again using "Adobe Acrobat 8 Professional" and now "enable the local save capability on the form", and save the file under a new name.

Comparing this file to the benchmark we may see a single change to the PDF binary internals that could indicate how to enable that (non standard, although widely used in the field) capability.

My (unrequested) opinion about the issue is, if we as a community don't go for supporting this undocumented (non standard) feature (which, until proven otherwise, looks like it could be as simple as a flag, nothing fancier or more complex) because it is "not documented, not standard", what is the whole point of going to great pains in a productivity suite such as OpenOffice, trying to mimic and implement every single .doc/.xls feature MS throws the world at?

Of course, it is much easier said than done decoding some obscure setting Adobe may have left undocumented just for the sake of having users locked in their own implementation, but the usefulness of the whole thing (and the increased reliance on PDF forms for all sorts of things) would put OpenOffice and the whole OpenSource users at a difficult position: if we can't create "useful" forms using OpenOffice, users will have to stay in the proprietary realm, and those that are using free software may need to return there for increasingly common processes based on PDF forms.

Created attachment 80502 [details]
PDF document catalog, with permisions enabled

The PDF in attachment 80496 [details] is enough to understand how the local save capability on the form is enabled.

In short, these permissions are enabled in the /Perms entry of the document's catalog. This entry specifies a permissions dictionary, in this case with a /UR3 entry. See PDF Ref. v. 1.7, 12.8.4, Table 258.

Quoting from that table:

"A signature dictionary that shall be used to specify and validate additional capabilities (usage rights) granted for this document; that is, the enabling of interactive features of the conforming reader that are not available by default.
For example, A conforming reader does not permit saving documents by default, but an agent may grant permissions that enable saving specific documents. The signature shall be used to validate that the permissions have been granted by the agent that did the signing."

The key point is that additional capabilities are bound to a digital signature, but not any digital signature (one the user could provide, or one that could be shipped with OpenOffice): it is Adobe's own signature, or one authorized by Adobe (PDF Ref. v. 1.7, 12.8.2.3, page 471):

"The UR transform method shall be used to detect changes to a document that shall invalidate a usage rights signature, which is referred to from the UR3 entry in the permissions dictionary (see 12.8.4, “Permissions”). Usage rights signatures shall be used to enable additional interactive features that may not available by default in a conforming reader. The signature shall be used to validate that the permissions have been granted by a bonafide granting authority. "

More important the quote under EXAMPLE:

"Adobe Systems grants permissions to enable additional features in Adobe Reader, using public-key cryptography. It uses certificate authorities to issue public key certificates to document creators with which it has entered into a business relationship. Adobe Reader verifies that the rights-enabling signature uses a certificate from an Adobe-authorized certificate authority. Other conforming readers are free to use this same mechanism for their own purposes."

The following document is also rather informative: http://www.adobe.com/devnet-docs/acrobatetk/tools/DigSig/Acrobat_DigitalSignatures_in_PDF.pdf

See 6.3.13 Enabling features via document-based permissions

"PDF enables a fully featured client with rich PDF interaction to grant document-specific permissions to less capable clients so that they can also use some of those features. Using this mechanism, a client that does not have digital signature capability may be granted that ability. When the permission is granted at the language level for a particular document, any associated signature related user interface elements would become enabled."

"For example, an author using Acrobat can grant permissions to enable additional features in Adobe Reader, using public-key cryptography. It uses certificate authorities to issue public key certificates to document creators with which it has entered into a business relationship. Adobe Reader verifies that the rights-enabling signature uses a certificate from an Adobe-authorized certificate authority. Thus, an Adobe Reader user that opens a reader enabled document can sign, fill in form fields, and otherwise perform actions that would otherwise be prohibited."

Resolving this bug as WONFIX:

In order to enable local save capability in the exported PDF form, OpenOffice needs a valid digital signature, entering "into a business relationship" with Adobe.

Thanks Ariel for the detailed analysis. I agree it's a WONTFIX for the time being, unless Adobe will grant a certificate.