[This blog post appeared first on my professional site at KHKonsulting.com]

A New Version of Acrobat

Have you noticed that it’s been more than two years since the release of Adobe Acrobat 9? Usually, Adobe releases a new version every 18 to 24 months, so a new version has been overdue. Today they let the cat out of the bag, and announced Acrobat X. There is already a lot of information available about what it is, and to some extend also how it is different from previous releases.

Take a look at the press release to get a quick overview of what’s new, or browse over two Adobe TV and watch the Acrobat X Tips & Tricks episodes. There is a lot of information available to give you a pretty good idea about what’s new and different.

User Interface

If you’ve attended one of my training seminars about Acrobat, you know that one of my pet peeves has always been that Adobe added to the UI clutter with every new release of Acrobat. Yes, every now and then they tried to clean it up, but at the end, it just caused more and more confusion among both novice, but also experienced users.

This time around, they took a completely new approach and ripped out the old menu and toolbar system and replaced it with something completely new. I am still trying to wrap my head around where things are now located, but in general, the new layout is a good idea. It will be much easier for the novice user to explore the UI and find new features that they might want to use, but for users who’ve worked with Acrobat since the early days of the product (in my case since Acrobat 3), it will take a while until we find all the tools that we’ve known by heart. But in the long run, I think it’s a good move, and I am more than willing to go through the learning process to get to know the new UI.

Plug-Ins

Every time Acrobat changed it’s UI in the past, there were major ripple effects through the plug-in community – things just did not work anymore, or not quite right, and we plug-in developers had some work to do to modify our plug-ins so that users could rely on these 3rd party components again.

If you have not yet tested your own plug-ins on an Acrobat X pre-release, don’t waste any time. Chances are that your code needs to be modified to work seamlessly with Acrobat X. If you need help with that, get in touch with me, I am a seasoned plug-in developer and I can certainly assist you with those efforts.

Favorite Feature

I don’t have a favorite new feature, but I have two favorite updated features:

Number one is what Adobe has done with Portfolios. In my opinion, Portfolios were one of the most underused features in Acrobat 9, and I hope that the updates to the Portfolio system will help to give that feature the necessary exposure so that we see more and more of these compound documents.

My number two updated feature is the much improved export function to other file formats. Whenever I had to create a MS Word document out of a PDF file in the past, it was always a hit-or-miss job – some documents worked reasonably well, others didn’t work at all. But regardless of how well it worked, there was always some editing necessary after the export to make the Word file look like the original PDF document. With the new export in Acrobat X, I get Word documents that look exactly like the PDF file. Great job, Adobe!

Every now and then I come across the question “What is the best way to learn scripting for Adobe Acrobat? Are there any books or other resources averrable?”. After doing some research, I think I finally found the best resource for beginners and for seasoned Acrobat JavaScript programmers that need a quick tip or a recipe to copy&paste into a project:

PDFScripting.com

The site offers content for both paying members and the general public. If you are new to scripting, and you don’t want to spend the money for a membership (yet), take a look at the free content at http://www.pdfscripting.com/public/department40.cfm – it walks you through creating your first AcroForm script, but also offers a number of videos that explain more complicated concepts. For the really good stuff however, you have to pay.

Ever wondered how to hook up a PDF form with an Excel spread sheet? Wonder no more! The article series “Acrobat, PDF and Excel Spreadsheets” teaches you more than you ever wanted to know about that subject.

You may remember my post about dynamic stamps in Acrobat. The PDFScripting.com site has a lot more information about dynamic forms and provides a number of very interesting samples (video link).

There is a ton more information available for both AcroForm and LiveCycle Designer scripting. This information comes in form of articles, videos, a copy&paste script library and downloadable sample files that illustrate a subject.

To get familiar with the web site, Thom Parker has recorded a video tour that helps to navigate the site, but also gives a pretty good overview about what’s available both for free and for paying members at “Take a tour of the PDFScripting.com website!” (video link).

So, no need to ask me for a good Acrobat scripting resource anymore, just go to PDFScripting.com and sign up for a year – it’s well worth the membership fee (and as Thom says in his tour video, no surprise at the end of the year, the membership does not automatically renew).

I wrote about my favorite tools around the PDF file format in the past. It’s time to add a couple more items to the list.

Over the last few months I’ve been working with two more products that I can recommend wholeheartedly:

PD4ML

There are a number of HTML to PDF converters available, but if your HTML is anything but basic, chances are that every single one of them does not render one or more features in your documents accurately enough… After looking at a number of them, I came across PD4ML and it looked good right from the first document I fed to it. There were a few problems, but PD4ML’s support was great in helping me out, even though I only had an evaluation license. At the end, all known problems were taken care of in the next formal release I received.

PD4ML is available as either a Java library or a .NET component. The Java JAR can actually be used as an application to get a good idea about how the generated PDF would look.

The library is available in a standard and a Pro version – there are a number of differences, which are listed in the “Products Comparison Chart” – the most important difference for me is that the Pro version supports font embedding.

ABCpdf

As I’ve mentioned before, I’m a fan of iText (mainly because it’s Java based, and I can use it on any system that has a Java VM), but I was looking for a library that had rasterization capabilities. I found ABCpdf, and it’s a great tool that does everything I want a PDF library to do (as long as I can use .NET, ASP or VB). It can read PDF documents, modify them and write them out again, create PDF documents from scratch, convert other formats to PDF (e.g. HTML – even with FLash support, EPS, XPS, SVG). It can even use OpenOffice.org to import MS Office documents. One of the more important features for me is the ability to access low level PDF objects – either to get more information about the PDF file and it’s objects, or to make changes that are not available via other high level calls. ABCpdf also allows me to do that.

ABCpdf comes in two versions, Standard and Professional. The “PDF Component Comparison Chart” on the web site lists the differences between the two versions.

Nuance (the people behind OmniPage and Dragon Naturally Speaking and a bunch of other things) release a competitor to the free Adobe Reader – the free Nuance PDF Reader (http://www.nuance.com/imaging/products/pdf-reader.asp). The feature list looks very promising:

• Fill and save PDF forms
• Annotate PDFs
• Convert PDF files to Word Excel or RTF
• Can disable JavaScript
• 100% compatibility with Adobe Acrobat (we have to wait to see how compatible it really is)
• Supports PDF Portfolios

Now to the things that it does not do:

• No support for Mac OS X or Linux
• No participation in online document reviews

I’ve not spent enough time with it yet to offer a detailed review, but it’s certainly a good alternative to the Adobe Reader. Competition is a good thing, maybe Adobe will take a few cues from Nuance for their next release of Reader.

Converting PDF documents to PowerPoint presentations is probably not something you need every day. I think I needed it once when the original PowerPoint file of a presentation I needed to give was no longer available, but the PDF file created from that presentation was. I did not have access to AnyBizSoft PDF to PowerPoint Converter back then, so a lot of copy&pasting took place.

Today you can download a free version of that software from GiveAwayOfTheDay.com. I’ve played around with the application a little, and it really does what it promises: PDF elements get converted to editable PowerPoint page elements.

Here is a list of the key features of AnyBizSoft PDF to PowerPoint Converter:

1. Convert PDF files to PPT presentations quickly and accurately
2. Retain all the layouts, images, and hyperlinks in the output documents
3. Produce an editable and dynamic PPT presentation with a few clicks
4. Convert up to 200 PDF files at the same time
5. Support Office 2010 and Windows 7

I cannot vouch for the last two list items, but I know that it worked for up to seven files, and that all the other claims are true. If you think you’ll ever need to convert a PDF file to PowerPoint, give AnyBizSoft PDF Converter a try – and if you do it (download and activate) today from GiveAwayOfTheDay.com it will not even cost you a dime.

Have you ever tried to fill a PDF form in Adobe Reader and to then save that filed document to your hard disk? Did it work? Chances are that it did not.

Have you ever thought about why the Adobe Reader is called “Reader”? The answer is pretty obvious, it’s because it is only reading and displaying (and printing) PDF files – that is, it is not writing them. That also includes that it will not save a modified document. You would need the “Adobe Writer” – or “Adobe Acrobat” as it is called for that.

But regardless of the name, we can “trick” the Reader into writing a filled form to the disk. OK, it’s not really a trick, Adobe did implement this feature, so it’s official, and we are not hacking or cracking anything.

Adobe has a server based solution that does allow you to create PDF files that are “reader enabled”: Adobe LiveCycle Reader Extensions ES
That technology allows you to “Fill in, sign, comment on, or save Adobe PDF files using only Adobe Reader”. Sounds like the perfect solution. Let me tell you a little secret: Whenever you hear the terms “Adobe” and “Server” in the same sentence, it usually means expensive…

Here is another secret – not really, it’s documented in a lot of places, but Acrobat users often don’t know about it: You can use Adobe Acrobat to “reader enable” PDF files as well. However, when you agreed to the EULA during the installation of Acrobat, you also agreed to using this technology only for a form with a maximum of 500 copies. The reason for that is of course, that Adobe still wants to sell the server based solution for document workflows that involve more copies.

So, let’s take a look at the EULA and find out exactly what we agreed to:

“15.12.3 For any unique Extended Document, you may only either (a) Deploy such Extended Document to an unlimited number of unique recipients but shall not extract information from more than five hundred (500) unique instances of such Extended Document or any hardcopy representation of such Extended Document containing filled form fields; or (b) Deploy such Extended Document to no more than five hundred (500) unique recipients without limits on the number of times you may extract information from such Extended Document returned to you filled-in by such Recipients. Notwithstanding anything herein to the contrary, obtaining additional licenses to use Acrobat Pro or Acrobat Pro Extended shall not increase the foregoing limits (that is, the foregoing limits are the aggregate total limits regardless of how many additional licenses to use Acrobat Pro or Acrobat Pro Extended you may have obtained). “

You may want to review that with your lawyer, I’m just an engineer, and in no position to give legal advice. I’ll however let you know what my interpretation of that section is: We have two options, we can either distribute our enabled form to an unlimited number of users, but we can only process a maximum of 500 unique responses. So, if we distribute our form to 1000 recipients, and we get 500 copies back, we are good. If we receive 501 replies, we can process the first 500, but the last one we cannot even look at. It also does not matter if we receive the filled out forms via a printed sheet of paper, or electronically. The second option is a bit more complicated, and you really should talk to your lawyer about that. To me it seems that you can distribute 500 copies of your form to 500 unique recipients, and they can then submit that form as often as they want. This could e.g. be a form that needs to be submitted once a week. Every one of your (up to 500) users/customers/clients has a copy of that form, and then once a week they fill in new data and submit the form.

Now we know what we can do with these forms, but we still don’t know how to use Acrobat for that. Let me show you a few screen shots.

Let’s assume you have a PDF form that you want to distribute, open that file in Acrobat and select “Forms>Distribute Form”:

This will bring up the dialog that we need to work with for the next few steps:

As you can see, I’ve selected to manually collect the responses in my email. That’s the most straight forward option and does not require any other configuration. The information presented below the selection does give you a pretty good idea about what it is. For now, let’s stick with the email option, but please, play around with the other options and let me know if you run into problems.

In the next step we specify the target location on our local hard disk for the protected (and now reader-enabled) copy of our file:

Now we need to add some information about us, the author:

We get one more chance to revise our decision about the delivery method, so if you want to take a different approach, and use Acrobat.com to collect the returned forms, here is your last chance. I will stick with the email option:

Once we click on the “Finish” button, the form will be prepared and saved, and Acrobat will display the Tracker interface. That dialog can also be opened via the “Forms>Track Forms” menu item (see the menu screen shot from above). I will talk more about that in a future post.

All you have to do now is to distribute your form. In a future post I will talk about how to process the returned data.

If allowing your users to locally save a form, you are done. They now can partially fill a form, save it, open it at a later time and continue with the form.

Have you ever needed a PDF version of a document, but you either did not have the correct source application (e.g. MS Word, PowerPoint, …), or you didn’t have access to a PDF converter (even though the free PrimoPDF is just a mouse click away). Or, did somebody email you a PowerPoint presentation, but you don’t have access to PowerPoint? But you do have access to a PDF viewer (either the free Adobe Reader, or Preview.app on the Mac). How would you convert a Word, Excel or PowerPoint document to PDF?

Google Docs to the rescue! Did you know that Google Docs can import a number of standard file formats into it’s word processor, spread sheet and presentation applications? Once you have imported your document, you just select to print… That’s it. Oh, I probably should explain that Google converts your document to PDF for printing purposes and then downloads that PDF to your computer. So just open that PDF file, and there is your document, now converted to a portable, easy to open file.

A while ago I tried to create an interactive dynamic stamp in Acrobat. These are dynamic stamps (like for example a stamp that automatically puts the current date into a field that is part of the stamp), but with a UI component that pops up and queries the user for some information that also gets embedded as part of the stamp (e.g. a phone number or a name).

I was not very successful. I could not figure out how to make sure that the UI only gets triggered when the stamp gets applied, and not when the stamp file gets loaded by Acrobat.

Then I came across an article by Rick Borstein titled “Add Dynamic Exhibit Stamps in Acrobat using a free stamp set” on the Acrobat for Legal Professionals blog. It had all the parts that are required, it even came with a couple of sample stamps. It also gave credit to the original source for that information: Acrobat JavaScript Guru Thom Parker

Thom provides all the theory behind why this works – very interesting to read if you are into that kind of stuff. It’s however not required to understand all that if you just want to use these stamps. You can just download Rick’s sample files and modify them until they fit your needs.

However if you want a dynamic stamp that shows more than just one line of interactively provided information, the examples do not work. They only provide one one-line input field and then put that one line on the PDF document. I wanted a stamp that could actually take several lines of user input and use that in a stamp. I had some work to do…

Acrobat’s JavaScript does allow to create custom user interfaces by creating a data structure and then calling executeDialog() with that data as parameter. Instead of a simple call to app.response() like in Thom’s and Rick’s examples, I needed to create a more complicated UI structure and embed that in the examples.

Here is the original code from the example:

var cAsk = "Enter Exhibit Number" ;
var cTitle = "Exhibit Number:  ";
if(event.source.forReal && (event.source.stampName == "#UdzyXagRctZoS5p43TZ43C"))
{
  var cMsg = app.response(cAsk, cTitle);
  event.value = cMsg;
  event.source.source.info.exhibit = cMsg;
}

var dialog = {
  retString: "",

  commit:function (dialog) { // called when OK pressed
    var results = dialog.store();
    this.retString = results["stxt"];
  },

  description:
  {
    name: "Stamp Information",    // Dialog box title
    elements:
    [
      {
        type: "view",
        elements:
        [
          {
            name: "Enter Multi-line Information: ",
            type: "static_text",
          },
          {
            item_id: "stxt",
            type: "edit_text",
            multiline: true,
            width: 300,
            height: 80
          },
          {
            type: "ok_cancel",
            ok_name: "Ok",
            cancel_name: "Cancel"
          },
        ]
      },
    ]
  }
}; 

if(event.source.forReal && (event.source.stampName == "#UdzyXagRctZoS5p43TZ43C"))
{
  if ("ok" == app.execDialog(dialog))
  {
    var cMsg = dialog.retString;
    event.value = cMsg;
    event.source.source.info.exhibit = cMsg;
  }
}

1. Open the “Exhibit+Stamp.pdf” document in Adobe Acrobat Pro
2. Go to the second page in this document – that’s the first stamp
3. Select the TouchUp Object Tool (e.g. via Tools>Advanced Editing>TouchUp Object Tool)
4. Right-click on the lower part of the stamp (where the UserData1 field) and select Properties… from the menu
5. Select the Options tab and check the “Multi-line” checkbox
6. Select the Calculate tab and click on the Edit button next to the custom calculation script and replace the old script with the one from above
7. Save the script with the OK button, then close the properties dialog

That’s it – just install the stamp file as described in Rick’s document. Done.

Of will of course be hard to see two or more lines in the relatively small stamp, so you may have to change the layout of the stamp to actually make use of the additional lines.f

If you’ve seen my resume – or talked to me lately, you know that I create Acrobat plug-ins for a living. When people hear that, they usually think something like “Don’t forget to pick up the dry cleaning” or “I need to bring my cat to the vet for the rabies shot”… Yes, I understand, this may not be the most exciting topic, but probably only because you don’t know enough about what these “plug-ins” are, so let me explain.

 

Adobe Acrobat is a very powerful tool, more powerful that most users actually realize. I wont go into any details about how powerful exactly – at least not today. Lets just say that it has something for everybody. However, you may need something in addition to what Adobe provides, something that still is in the general area of PDF. Adobe may not have considered your needs because either the target market for “your” feature is too small, or to far out there… Or you are so far ahead of everybody else that they have not even thought about that feature yet.

Adobe did however do a very interesting thing: They created an interface that allows 3rd party developers to create solutions based on Adobe Acrobat – using plug-ins. It is a very powerful interface, and hence not something that you can pick up in an afternoon. There are several thousand pages of API documentation that one needs to understand before a plug-in should be written.

A plug-in is – from a technical point of view – a module or library that gets loaded dynamically at runtime. Acrobat will scan it’s plug-ins directory and will load any modules it finds. Once loaded, such a plug-in can extend Acrobat by e.g. adding menu items, toolbuttons, or event handlers (e.g. a function that gets executed whenever a documents gets loaded).

 

Interestingly enough, the plug-ins directory of a fresh Adobe Acrobat installation is not empty… A lot of Acrobat’s functionality is actually implemented as plug-ins. You can verify that on a Windows system by temporarily disabling all plug-ins by holding down the Shift key when bringing up Acrobat. That will load the application without any plug-ins. When you compare the toolbar or the menu bar with a fully loaded application, you’ll see what portion of the Acrobat core functionality is actually implemented in plug-ins.

The plug-in interface has different abstraction levels (COS, PDE, AV, …). If there is enough interest, I will provide information about how to navigate that API, and how to structure a plug-in.

The Acrobat SDK is available for free from Adobe’s Acrobat Development Center.

Here are a few examples of commercially available plug-ins that I’ve used:

• Enfocus PitStop Professional:
  This is a preflight tool.
• Quite Imposing Plus:
  The best PDF based imposition tool that I am aware of.
• Enfocus Browser:
  Allows to review and change the internal structure of a PDF file.

OK, I have to admit, the title is just for show I don’t really want to gut a PDF – that would mean to kill it, and PDFs are pretty useful, so we should treat them well…

What I’m after is to extract arbitrary information from a PDF file – information that may not be accessible in any other way. Some 3rd party Acrobat plug-ins save information in a PDF file so that once the document is opened again, the plug-in “knows” that the current file was already processed, or that a user interface window can be populated with the previously saved settings, or … There are many reasons why that could come in handy.

If you take a look at the PDF Reference document, you can find all the information necessary to understand how data can be saved in a PDF file. Adobe does allow 3rd party developers to store information in a PDF file as long as it is clear that the data is private. The developer can make sure that nobody else reads that information by accident by using a four letter developer prefix for all such data.

I’ve mentioned before that there are tools that allow us to look at the structure of a PDF file (e.g. the Enfocus Browser, or with Acrobat’s own Preflight tool). For now let’s assume that the data we are interested in is actually saved in the PDF’s metadata stream – if you don’t know what that means, please go back to the PDF Reference document.

[more after the jump] For this example, let’s try something simple that just illustrates the process and the tools we need. With that knowledge and background, it is easy to perform more sophisticated tasks with PDF files.

Every newer PDF files does not only contain the meta data in form of the document info dictionary, but also as XMP meta data – this is a XML based format. Let’s try to extract that XML data stream from a PDF file.

Because I don’t want to hide the interesting parts of the solution by infrastructure, I am hardcoding the PDF filename and the text output file name, I’m also assuming that the iText library JAR file is in the same directory as the source code.

Here is the complete program, I’ll go through the different sections once we’ve compiled and executed it:

/* based on some sample code from iText library */

import java.io.*;

import com.lowagie.text.Document;
import com.lowagie.text.DocumentException;
import com.lowagie.text.pdf.PdfReader;
import com.lowagie.text.pdf.PdfDictionary;
import com.lowagie.text.pdf.PdfName;
import com.lowagie.text.pdf.PdfStream;
import com.lowagie.text.pdf.PRStream;

public class MetaData {

    public static void main(String[] args) {

    System.out.println("Trying to extract XML metadata");

        try {

            PdfReader reader = new PdfReader("first.pdf");

            PdfDictionary dict = reader.getCatalog();

            PdfDictionary metaData = dict.getAsStream(new PdfName("Metadata"));
            if (metaData == null)
            {
                System.out.println("Cannot get metaData");
                return;
            }

            if (metaData.isStream())
            {
                OutputStream f = new FileOutputStream("metaData.txt");

                byte[] data = PdfReader.getStreamBytes((PRStream) metaData);
                f.write(data);

                f.close();

            }
            else
            {
                System.out.println("Metadata is not a stream object");
            }

        }
        catch (Exception de) {
               de.printStackTrace();
        }
    }
}

Let’s assume that the source code is in a file named MetaData.java, to compile and run the program, we would need to execute the following commands:

javac MetaData.java
java MetaData

Before you execute the program, make sure that there is a PDF file named “first.pdf” in the same directory as the program and the iText library.

How Does It Work?

import java.io.*;

import com.lowagie.text.Document;
import com.lowagie.text.DocumentException;
import com.lowagie.text.pdf.PdfReader;
import com.lowagie.text.pdf.PdfDictionary;
import com.lowagie.text.pdf.PdfName;
import com.lowagie.text.pdf.PdfStream;
import com.lowagie.text.pdf.PRStream;

In the next few lines, we define our class and declare our main function. Also, the whole iText related code is in one try/catch block. For a real application, you want to create smaller try/catch blocks so that you can recover from problems.

public class MetaData {

    public static void main(String[] args) {

    System.out.println("Trying to extract XML metadata");

        try {

Now we are ready to create a new PdfReader object – this is how iText accesses the data in a PDF file. From that PdfReader object we can then get the “Catalog” which is the root object of all COS objects that are used in this dococument:

            PdfReader reader = new PdfReader("first.pdf");
            PdfDictionary dict = reader.getCatalog();

The meta data is stored as a stream (if you don’t know what that is, read up on it in the PDF spec) as a direct child of the Catalog dictionary (again, if you don’t know what that is, read up on it). This means that we can access it without any further navigating through the COS objects. For a real project, chances are that you have to go a few more levels deep into the COS structure. The PdfDictionary object has a method to get a stream:

            PdfDictionary metaData = dict.getAsStream(new PdfName("Metadata"));
            if (metaData == null)
            {
                System.out.println("Cannot get metaData");
                return;
            }

When it comes to software, I’m not a very trusting person, so I want to make sure that we are indeed dealing with a stream and nothing else. Therefore I will call the isStream() method to find out if that’s the case. If we are dealing with a stream, I’m creating a new FileOutputStream (a text file that will receive the XML data), and then I am reading the actual COS stream data and writing it to the output file. iText will take care of any filters that were applied to the stream data (e.g. compression), so I don’t have to deal with that directly.

           if (metaData.isStream())
            {
                OutputStream f = new FileOutputStream("metaData.txt");

                byte[] data = PdfReader.getStreamBytes((PRStream) metaData);
                f.write(data);

                f.close();

            }
            else
            {
                System.out.println("Metadata is not a stream object");
            }

That’s it. Now we just need to make sure that we do have catch block for our exception handler:

        catch (Exception de) {
               de.printStackTrace();
        }
    }
}

Instead of saving the XML meta data to a file, we could have used a Java based XML parser and extracted data from it.

The same technique can also be used to read other data from a PDF file (e.g. names, numbers, …).

Let me know if you have more questions about either iText, or how to access information in a PDF file with it.