This is one of these differences between the application specific extensions that sneaks into the description of the core language: Every web browser will display an alert message box when this line of JavaScript gets executed, but Acrobat does not know about the alert function.
Acrobat does however provide very similar functionality via the app. See the description in the SDK documentation for more information. We can use the simplest form of app. The first line again is the code I am executing, the second line shows the return value of what got executed. This takes care of informing the user about what our program did.
Often there is also a requirement to ask the user for input. In a web browser, the JavaScript program would use the prompt function, which again does not exist in Acrobat this is example2. We already know what to do with the second line, to replace the prompt function call with something that Acrobat understands, we will use the app. Once you have a good understanding of the core language, you need to become familiar with how JavaScript is used in Acrobat.
If you need any help in learning JavaScript, or in how it is used with and in Adobe Acrobat, keep in mind that I do run a consulting business and part of what I do is to provide training. Full disclosure: Some of the links to books on this page use my Amazon affiliate link, so when you order through one of these links, I will get a few cents. Thanks for this post! It will help me a lot for my little scripting project. I keep in mind that you offer consulting services. Thanks for the great introduction to Javascript for Acrobat DC.
Unfortunately, many of these tasks involve alot of manual work with Acrobat. I was hoping that I would be able to automate the process using the GUI, but this is not possible. Having a dedicated introduction to this variant of JS is extremely helpful as it prevents alot of wasted time learning about the unecessary part of JS.
Many thanks once again. It has to be done all at once. Notice that in the loop there is a function called console. It's in the fourth line. This function writes text to the Console Window and it will be discussed in the next section.
Here's an example of a function that does not have an easy equivalent on the regular Acrobat menus and toolbars. Enter the following line into the Console Window and run it:.
Acrobat will create a new, blank PDF document. This is perfect for trying out new ideas before applying them to a working document. The results of this operation are shown in Figure 7 below. Note that yet again, the result is something different. The result shown in Figure 7 tells us the type of object created. This result is only useful in letting us know the function worked. If app. Both of these situations would have been displayed in the Console Window.
The path property is exactly what you might think it should be. It's the folder path of the current document. Since the current document was just created with app. The result will look something like this:. Of course, this information is easily available in the Document Properties dialog. The advantage to using the Console Window is to make this information available to copy to the system clipboard for use with another script in Acrobat or for something else.
Besides testing code, the Console Window has one other important role in debugging JavaScript. It is the standard location for displaying status and error messages. The Acrobat JavaScript environment has a built-in error handling system. When something goes wrong, this error-handling system usually displays some helpful message sometimes in the Console Window, so this is the first place to look when things aren't working.
In addition, you can create your own status and error messages to display here. As an example, let's execute something that will cause an error. Enter and run the following line of code in the Console Window:. This line of code instructs Acrobat to open a file xx. Acrobat responds by generating an error, which is displayed by the Console Window, shown in Figure 8. This message is critical to understanding why the code failed, especially if the function call is buried in several lines of code inside another script.
Always check the Console Window first when something goes wrong. Note that the second message on the line indicates a security error. For our purposes, this is an erroneous and unhelpful message. There was no real security error, and while it may then seem that Adobe is deliberately trying to either terrify or confuse us, there is a reason the message is being displayed.
In fact, the message is not related to the JavaScript engine at all. It is the result of the Acrobat security model, which was made much more robust in versions 9, X, and XI by adding a security layer.
This layer blocks operations that don't fit with Acrobat's sense of rightness. JavaScript operations or errors that relate to external resources on the web or local file system tend to spook this security layer, which then throws out miscellaneous security errors. If you work with Acrobat JavaScript for any length of time, you'll find all sorts of operations that have nothing to do with security, but nonetheless generate security errors. We can also create our own messages for display in the Console Window.
This object provides a few functions for manipulating and accessing the Console Window, but for our purposes here the console. This function displays a single line of text on the next available line in the Console Window. The following line of code displays the words "Hello Acrobat. The console.
Just place a few console. It is up to the developer to decide what information to display. This information should be relevant to the state of the script. For example, the following line helps us understand how JavaScript events work in Acrobat. The code can be placed in any script location in a PDF file. It is a good practice to use this code or something like it whenever you start a new document scripting project to get a feel for how the different scripts will interact.
Watch the Console Window to monitor the sequence of scripts that are executed as you open and close the document, navigate between pages, move the mouse around the document or perform other actions. If you are developing scripts that will be used in Adobe Reader, then it is a good idea to be able to test and debug them in Reader. Adobe added Console Window support to Reader in version 7. However, setting up Reader to actually display the Console Window was very difficult.
It required installing special scripts and manually changing Acrobat settings in either the Windows Registry or the Macintosh settings files. It has become much easier in Reader XI. There is only one thing you need to be able to do to use the Console Window, and that is to display it. Displaying the Console Window in Reader is a bit more difficult than one might think it should. Reader does not have the keyboard shortcut, a menu item, or a tool button for displaying the Debugger Window.
This leaves only two options: create your own tool button or menu item or cause a deliberate error. This is how you throw exceptions in JavaScript. Applies to: Creative Suite. You do not need to enable JavaScript in the latest version of Firefox.
Verify if JavaScript is enabled. Microsoft Internet Explorer Windows only. On the Security tab, select the Internet zone icon. Click Custom level. In Security Settings, scroll down to Scripting. Select Enable under Active Scripting. Click OK. Select Trusted Sites and repeat steps 3 - 6.
0コメント