I am processing a collection of PDF files in which I execute a script for each 3D annotation found. However, some PDFs are secured and addScript method on Doc is throwing an exception : "NotAllowedError: Security settings prevent access to this property or method.".
Is it possible to remove the security to be able to call addScript?
The PDF file won't be saved at the end. Is there a way to open the PDF as a non-secured one, just the time to do the treatment?
Thank you in advance.
1. Security belongs to the file as a whole rather than just the open document, so however you remove security you need to save the file before it takes effect.
2. There is no way for OLE to use the password to remove security, anyway.
Not if the PDF security forbids it.
AcroAVDoc document = new AcroAVDoc();
if (document.Open(a_pdfPath, ""))
CAcroPDDoc pdDocument = (CAcroPDDoc)document.GetPDDoc();
Object jsObject = pdDocument.GetJSObject();
Yes, GetJSObject is the bridge. No idea if it checks document security, sorry.
However, I can't execute a script right from a file. I could try to decypher the script file and "execute it" with bridge objects but I encounter another issue described there : https://forums.adobe.com/message/10776324#10776324
I am not a native english speaker so I hope this makes sense to you.
Since you are building an application that a user must install, why not also install an application level script in Acrobat & call that via the bridge?
Well it is a good idea but have some downsides :
- The scripts are written to be executed in an annotation 3D scope. We can (at runtime of an OLE application) encapsulate them to be called from an application scope and this is part of the program I have written. The script we wanted to add using the method 'addScript' was an encapsulation having all scripts put in a function with a parameter scene given. If we add or remove test scripts, we would need to update the encapsulation of the scripts and re-install them. We'd like to have those files kept for a context3d scope as the files will be processed in another context than Acrobat's.
- On the ideology level, we are running test scripts. By definition, we should not intrude more than necessary the context in which the test is processed to avoid side effects. Application level scripts should be kept for adding tools into the application, not some specific behavior for some specific files, especially if you can't control the content of the scripts inside those PDFs. They are not ours, they were created by other companies and we are using some of them to test our functionalities, and have a reference of bugs fixed to avoid regressions.
If addScript is viable, you should probably update your working practices to ensure that nobody is permitted to set document security - which has no value except as a nuisance to you.
addScript is viable only because we won't save the PDF after the tests. And it is a nuisance still.
It seems to work fine except for PDFs that have no AcroForm/Fields.
It is strange that this method is put on Fields object instead of CAcroPDDoc.
Well, I guess I gonna go for a mix and hope there is no secured PDF with this case.