These forums are now Read Only. If you have an Acrobat question, ask questions and get help from one of our experts.

Button control of a second, read-only document

asmohr
Registered: Sep 2 2007
Posts: 25

Hi folks,

I'm trying to change pages in a second document using buttons in the first document.

The logistical bind, and the reason for the project, is that the second/target document is copyright and changes that require redistributing a modified version of it will violate the owner's copyright.

It is a PDF manual, distributed by a very large corporation, describing software used by tens of thousands of people. But BigCorp has amateurs doing the doc. The engineers pick it up after the product is released, so it comes out months later. The poor engineers don't have a clue about document design. The PDF does not have any bookmarks and there are no hotlinks anywhere. There are 887 pages and the first 20 of those are the TOC.

I would like to distribute an add-on document that would patch some of these problems. My first version, to test the concept and interest in the project, would be a 20 page document that corresponded to the table of contents. When you page through my doc, onPageOpen scripts would change pages in the second document. My document would have buttons labeled with the page numbers in the TOC so when you find the listing the target document's TOC, you click the page number button in my document and it changes the page in the target document.

The only way so far that I've been able to get any functions to work in the target document is to put them in a Folder-Based JavaScript file in Acrobat's JavaScripts directory. That script creates a submenu that has a separate command for each page change. I don't seem to be able to change pages directly from Document-Based functions, onPageChange or Button functions, but I can call the menu commands from those triggers.

By creating a menu command that lets the user set the target document to "disclosed", then buttons in my controlling document can call the menu functions inserted by the Folder-level script and change the page of the disclosed, target document.

So this requires about 650 buttons in my control document. I can automate generating those. But it also requires creating a Folder-Level Javascript that adds a submenu with over 650 menu entries in it.

Is this going to make Acrobat open absurdly slowly? Can Acrobat handle that many menu entries at all?

I could write a startup/cleanup OS commandline script that copies the JavaScript file into the Javascripts folder and removes it when done. That would avoid it getting in the way with other uses of Acrobat. But will it choke my project?

I could write a test that would add 100 or 650 menu items with all the same function code and see what it does.

But if someone else already knows what to expect, I would appreciate any advice.

And if anyone has any ideas for getting around the limits I've hit, like how to not HAVE TO add those menu commands in the first place to be able to execute a function on a second document, that would be really helpful.

Thanks for any comments,
August

thomp
Expert
Registered: Feb 15 2006
Posts: 4411
You didn't say what version of Acrobat you're using?

You keep saying "changing pages". Do you really mean navigating to a page? So you want to add document navigation features? If this is the case, then there is absolutely no reason for a folder level script and menu items. You can do this all within the documents.

You can find gobs of information on scripts for navigating in a PDF here.
http://www.pdfscripting.com/public/department43.cfm

If you want to use a multidocument strategy for this, the both documents should have this line of code in a Document Level Script:

this.disclosed = true;

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Thom Parker
The source for PDF Scripting Info
www.pdfscripting.com
Very Important - How to Debug Your Script

asmohr
Registered: Sep 2 2007
Posts: 25
Hi Thom,

Sorry I'm verbose. It's a complicated issue. Unfortunately, busy people like yourself have a tendency to skim over long postings like mine. I'm sorry that I haven't distilled it down further.

Thanks for the suggestion about Document Level Scripts, but I think you missed the implications of my second sentence:

"The logistical bind, and the reason for the project, is that the second/target document is copyright and changes that require redistributing a modified version of it will violate the owner's copyright."

If I could add any document-level scripting to the second document, I would not have this challenge; it would be pretty straightforward. Instead, I'm trying to find a work-around.

As my next paragraph says, this is a big corporation; you've heard of them. They have lots of lawyers who need to justify their jobs. And they don't do proper PDF documentation because they're cheap. Or maybe because this product actually comes from a very small company that got acquired by BigCorp and SmallCo never did have writers because they were a small startup. Regardless of the reasons for the inadequate doc, that's the need I'm trying to fill.

I can add a folder-level script that adds a menu item that allows the user to set "this.disclosed = true;" from within the second document. If they run that first, manually, then the scripts in my controlling document can at least access the target/second document.

All the scripts in the first/controlling document include tests to make sure that there is a disclosed document available.

But without document-level scripts in the second/target document, all my document level scripts have to live in the first/controlling document. And the only actions that I've been able to execute from a button in the first document that will have any effect on the second document are those that run menu commands.

Because my menu commands are written so that they only operate on a disclosed document of the correct filename, then I can trigger them from buttons in the first document and they will find the second document (as long as the user has run the command to disclose it) and then they can do things like navigation and selection.

IFF I could add buttons or annots to the second/target document, that would be the easy solution. But that would require getting BigCorp to distribute a revised version of their document with my modifications. If I could get them to do that, maybe I could get them to just create a proper PDF with the needed hotlinks.

But until then, until I'm talking with the appropriate decision maker about that, I'm still looking for a way to help tens of thousands of users by giving them a document that works better than what BigCorp has provided.

My best shot seems to be a Commentary/Update/HotLink-Navigation/Errata document that I can distribute that can take some kind of control of the problematic target document.

If I could figure out how to use my controlling document to add a Document-level script to the user's personal version of the PDF they got from BigCorp, then I would not be distributing BigCorp's property. But Acrobat Security prevents that, and with good reason.

It seems as if the only things I can trigger from buttons in my controlling document that can do things to the target document are menu commands. And it seems menu items are the only things that I can add, because I cannot change the target document, even from a menu command. Menu commands are at the APP level, not in the document.

Do you know any way around this? I'm open to suggestions that meet the fundamental limitations of the problem.

If not, then I'm looking at adding over 650 menu items, just to get hotlinks for the TOC.

Do you happen to know of any limitations that would prevent my doing this or make it an impractical solution?

As for Acrobat version, I'm assuming my users will have Reader v8 or later. I have Pro v6. I can write Folder-Level scripts that I add to the Acrobat v8 Javascripts folder that use v8 objects and methods. I can use Pro v6 to add buttons to my controlling document that will trigger the menu items that are added in Reader v8 and which can use v8 objects and methods.

Thanks for your time. If I'm still confusing you, just ask and I'll attempt to clarify whatever is not yet clear.

Thanks
August
thomp
Expert
Registered: Feb 15 2006
Posts: 4411
You are right, This is way too long to read;)

If you need the privilege that comes with a folder level script, but you don't want to make all your users install a folder level script, there is a way around it. If a PDF is certified, and the user has the certifying signature on thier system, then that PDF can run privileged code.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Thom Parker
The source for PDF Scripting Info
www.pdfscripting.com
Very Important - How to Debug Your Script

asmohr
Registered: Sep 2 2007
Posts: 25
thomp wrote:
You are right, This is way too long to read;)
My apologies. I'll try again distilling to just the Acrobat JavaScript issue, not the reasons behind the problem.

Quote:
If you ... don't want to make all your users install a folder level script,
I can have my users install a folder-level script if that is the only way. I can script that for them.

Quote:
there is a way around it. If a PDF is certified, and the user has the certifying signature on thier system, then that PDF can run privileged code.
Thanks, this is a useful thing to know, but in this case the issue from the start is that I don't own the original PDF.

Not owning the PDF, the only way I could change what's in that PDF is to re-distribute it, which violates the owners copyright. So I can't change what's in the PDF.

It looks like the ONLY way to do ANYTHING inside a PDF that I cannot change is with folder-level scripts. Is that right?

I can trigger those folder level scripts with anything at my disposal inside a PDF that I do own.

I can identify the document to use if it is disclosed, and the user can disclose it by running a folder-level script.

I think those are my limitations. Am I right? Are there any other workarounds that you can think of?

Thanks again for your help,
August
thomp
Expert
Registered: Feb 15 2006
Posts: 4411
asmohr wrote:
It looks like the ONLY way to do ANYTHING inside a PDF that I cannot change is with folder-level scripts. Is that right?
This is correct!

asmohr wrote:
I can trigger those folder level scripts with anything at my disposal inside a PDF that I do own.
Yes, But you don't need to add menu items to Acrobat. All you need in the folder level script are a couple of trusted functions that allow you to navigate the other document.

Did you look at the article on navigation that I posted earlier. As far as technique goes, everything you need is in there.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Thom Parker
The source for PDF Scripting Info
www.pdfscripting.com
Very Important - How to Debug Your Script

asmohr
Registered: Sep 2 2007
Posts: 25
thomp wrote:
Did you look at the article on navigation that I posted earlier. As far as technique goes, everything you need is in there.
Not as closely as I should have because I was chasing this make-or-break issue. I had already started thinking that maybe I could do it with navigation functions instead of the brute-force of 650 menu items. I will look at that article again.

Thank you very much,
August