How I Became A PDF JavaScript Expert
I had no training or formal education in computers or programming. I was working as financial planner in the late 1990s.
There was a lot of paperwork, and it was all handwritten, with carbon copies: One for the client, one for the file, one for head office. Lots of account types. Lots of investment companies. All with different paperwork. More time was spent on paperwork than client conversations, analysis, and solutions.
"Don't worry," they repeated. "This will all be automated one day soon." One day never came. Around 2004 the paperwork started to come electronically in PDF format with fillable fields. Typing was definitely better than handwriting, but you couldn't save your work with free Adobe Reader back then. You would have to leave the form open until you were ready to print it.
Take the Acrobat Pro/JavaScript eLearning Course Acrobat Like A Pro
At the time I had no idea that Adobe had a paid version that allowed the saving of form field data. Then one day a colleague was showing me something and he opened a PDF form he had saved with the fields filled in. "How did you do that?" I asked.
"Do what?" he asked back. Apparently, he had a copy of Adobe Acrobat Professional on his computer but wasn't sure how he got it or where it came from. He was saving PDFs with filled in form fields on a regular basis and assumed everybody could do the same.
I immediately downloaded and installed a free trial of Adobe Acrobat Professional, version 6. While saving completed form fields was nice and would make my life somewhat easier, I realized there were issues that needed to be addressed.
Sure, I could anticipate ahead of time which form(s) I would need for a client meeting, fill them out with basic information, save them, and resume completing them during the meeting. But what if I needed a form that I did not anticipate ahead of time? It was back to square one, completing all the information while the client waited. Yes, I could save all the forms I completed for a particular client, but what are the chances I would ever need the same forms for the same client again? Probably zero for an account application. What if it was a form that I would potentially use a lot for the client in the future? I could save it but the next time I needed it, the form would most likely have changed, as happens frequently in that industry, and the saved version would be useless. And what about the amount of hard drive space taken up by thousands of saved PDF files? You can get a thumb drive at the grocery store checkout now with more storage than five of my $4,000 (at-the-time) laptops.
NECESSITY IS THE MOTHER OF INVENTION
What if there was a PDF template with form fields for entering standard data? And what if that data could be saved and recalled into any form? That would solve the issues. I began researching the capabilities of Acrobat Professional with purpose and determination. I soon discovered that form field data could be easily exported into a "Forms Data Format" file (.fdf file extension) and then imported in a split second into another form. The size of these data files was insignificant (approximately 2 KB). The key was consistency in field naming.
As long as the field names in the exporting PDF form matched the field names in the importing PDF form, a client data file could be created, exported, and saved once, then instantly imported into any properly mapped form. Before my 30-day free trial of Acrobat Professional was over, I had created a template for exporting form data and mapped the fields to my 50 most commonly used forms. Each form had a non-printable button field at the top labelled GET CLIENT. The template had a CREATE/EDIT CLIENT button at the top. My main mistake in creating this system was using the Execute A Menu Item command in the mouse-up button action (more about this later). That "mistake" turned out to be a huge blessing. Without it I wouldn't be the PDF JavaScript expert I am today.
BUSINESS OPPORTUNITY
I knew there was high demand for my creation. I also knew there would be a lot of upkeep with field mapping for constantly changing forms. If I was going to sell this to other financial advisors, I needed a few things:
A way to prevent multiple parties from sharing the platform so that I would be fairly compensated by all users.
A way to easily collect an annual fee to compensate me for all the upkeep throughout the year.
The second bullet point was easy. No email updates once the expiry date passed without renewal, plus something much better. A time bomb was installed to prevent use after the expiry date, as well as popup warnings "your license will expire on xx/xx/xxxx" that started about a week before the expiry. As customers came to rely on this system and never wanted to go back to doing things "the old way", I had no problem collecting renewal fees, and had close to a 100% retention rate.
To address the first bullet point I set all the form fields that identified the user (Advisor Name, Dealer Name, Rep Code, etc.) to read only, ensuring that they could not be easily altered. I encrypted the forms so they couldn't be changed without entering a password. I also hid the identifying user data in the template so that it would import into the forms whenever a client was imported.
Once it was ready to go, the advisors in my office instantly bought in. Not only were they longing for the day that was repeatedly promised to arrive, but they also practised cost/benefit analysis for a living, and this one was a no-brainer.
Word spread. Sales increased. Demand for additional forms turned 50 into 200+. Things were moving along nicely and then…
PANIC SETS IN
The excitement of a new sale started to evaporate with one phone call.
"It doesn't work. Nothing works. I followed the instructions to a tee."
After checking the files and running a few other tests, I couldn't figure out why it wasn't working. Then I asked the obvious question. "Which version of Acrobat Professional are you running?"
"7.0" was the reply. "Let me run some tests and get back to you" I said. I was a recent owner of Acrobat Professional 6 and it was working fine. I saw no reason to update to version 7. In fact, I didn't even know there was a version 7. The new customer did not have Acrobat Professional until she purchased my program. Adobe had recently updated to version 7, so that was the one available to her.
I immediately purchased, downloaded, and installed Adobe Acrobat Professional 7.0 and opened my template and forms. None of the buttons worked.
A NEW CAREER FLOWING OUT OF A MISTAKE
By opening the console, I noticed the same error repeated for every time I had clicked the button:
InvalidArgsError: Invalid arguments.
App.execMenuItem:1:Field Button1:Mouse Up
I checked the menu item for importing and exporting form field data and the wording had changed slightly for both actions (something like Import Form Data was now something like Import Data To A Form).
What am I going to do? I thought. I'm going to have to rewrite the buttons on all 200 forms so it works for this customer. Too much work. I'll issue a refund. No. Then not only will I lose this customer, but I will lose all future customers who own version 7 of Acrobat, or who don't own Acrobat, but will own version 7 once they purchase the software. And what about menu item wording changes in future versions? And what about different menu item wording in previous versions?
I researched some more and found the buttons could be programmed with JavaScript to execute the same processes that were being called by the menu items. The scripts worked on both versions, and I realized the scripts would never change no matter how many times they changed the wording of the menu items. I would have to replace all of the buttons with the Run a JavaScript mouse-up action instead of Execute a menu item. While researching this button fix, I learned something very important.
Almost anything you can do with the User Interface in Acrobat Professional you can also do with a script, which makes automation of repetitive tasks possible.
To this day, the only button command I use is Run a Javascript. A script can make the form do exactly what you want, without being limited by what's in the list of button commands.
MY FIRST AUTOMATION PROJECT
Through more research I learned about Batch Processing (now call Actions). I set up a Batch Process to make the following changes to all 200 PDF forms in my library:
Remove the password encryption from the forms so changes could be made.
Remove the Execute a menu item command from the buttons.
Add a Run A JavaScript command, and the script, to the buttons.
Re-apply the password encryption.
Save the forms.
Once the Batch Process was set up, the above was done in a matter of minutes. I created another Batch Process that I used to import the advisor form data to the library when setting up new clients. Acrobat Professional contained all the functionality for these processes.
HOOKED ON AUTOMATION
One of the objections I heard often against purchasing my system was "It's going to take forever to enter all of my clients' data into the template." Here's the thing. If you're going to enter client data into the forms directly, you're going to have to do it anyway. With my system, you would only do it once. If you have five forms for the meeting, you're only entering the client information once. So what you do is take five minutes to create the data file for the client prior to the next meeting, and you never have to do it again. Before you know it, it's a rare occasion that you don't have a data file for a client when you check before the meeting.
Most advisors understood this. Most of their administrative staff understood. But I still had some holdouts that couldn't grasp the time/value proposition. I went back to researching.
Soon I was able to add a feature that would automatically create all the fdf files from a spreadsheet. By naming the column headings to match the system field names and saving the spreadsheet as a tab delimited text file, it would loop through all the rows (clients) to create the fdf files for the entire client base.
I was hooked on paperwork automation. I have automated thousands of tasks for companies and individuals around the world since the original project and have become a JavaScript expert in the process. I believe my humble beginnings, with a lack of formal education in this area, provide me with an advantage when it comes to teaching and sharing my knowledge. The number of things I have figured out when all the experts said "no you can't do that" or "not possible" proves my ability to think outside the box.
I love a good challenge. The fact that it seems to be happening on a weekly basis these days keeps me sharp, and keeps me learning. Every once in while a seemingly unsolvable issue dogs me for weeks, sometimes months, then out of nowhere the proverbial lightbulb goes off. I just had one of those moments on a recent project, which was a game changer for me. If you stick with me I'll share it with you soon, as I use this space to share my knowledge, expertise, experience, tips, tricks, and maybe a few proprietary secrets. See you soon…