Every now and then, it actually helps to read the documentation – or, the release notes in this case: “11.0.3 Planned update, May 14, 2013Acrobat and Adobe Reader Release Notes”

The section about the EchoSign integration sheds some light on this new feature: Acrobat and Reader are trying to intelligently determine if a document needs to be signed using the EchoSign online service. However, the algorithm seems to be getting it wrong a lot: The presence of the term “sign” or “signature” will actually trigger this banner that claims that it has detected signature field(s). In the document above, that could actually be true, but what about this?

In my opinion, this signature field detection needs to become much smarter, and it should also be possible to turn this off via a preference setting – both on a document basis and in the application.

The release notes actually do provide some information about how this new behavior can be turned off, unfortunately at this time only via a registry key in Windows. Here is how you would manually change this setting in the registry:

Bring up the registry editor by clicking on the Windows Start button, then enter regedit into the search bar:

Once the registry editor comes up, navigate to the path outlines in the release notes (HKLM\SOFTWARE\Policies\Adobe\(product name)\(version)\FeatureLockdown\cServices) – HKLM stands for HKEY_LOCAL_MACHINE:

On my system, the “cServices” entry does not exist under FeatureLockdown, so I need to create it by right-clicking on the FeatureLockdown key and selecting to create a new key named cServices (it will first create a new unnamed key, we have to rename it in a second step).

Once we have the cServices key, we right-click on that key and select to create a new DWord with the name bEnableEchoSignDetection – the default value will be 0, so we can just accept that, and don’t have to set the value: We want to disable the signature detection.

When we now open the PDF file from above again, everything looks good: The signature field detection is no longer triggering the green bar:

To make things easier for you, I’ve created two registry files that you can download and run by double-clicking on them that will disable the EchoSign field detection on Acrobat XI and Reader XI:

Disable EchoSign detection for Acrobat XI

Disable EchoSIgn detection for Reader XI

Unfortunately I have not yet figured out how this can be disabled on a Mac… But, I’m still trying, so expect an update soon.

The post No Signature Required! appeared first on KHKonsulting LLC.

Unfortunately we only have a button to acknowledge the problem, but no way to fix this. As you can see, my MacBook Pro is configured so that it will not run applications from unidentified developers automatically. This is usually not a problem, because I can manually start an application and give it permission to run on my computer (see this link for more information), but in this case, I don’t know where the application is.

So, how do we fix this problem? I want my Acrobat to be updated, so I need to figure out how to get around the security error. I could of course lower my security and allow any application to run, but that would expose my computer to some potentially nasty stuff, and I don’t want that.

To figure out what application is causing this problem, I left the dialog up and started the Activity Monitor – to make the list more palatable, I filtered for entries that contained the term “Adobe”:

The application “Adobe Acrobat Updater” is in the list, and when I bring up the Inspector for that entry, I can actually see the path to the application:

This makes it possible to navigate to the location of the application in Finder and right-click on the application to start it. The security dialog that gets displayed now does offer the option to open the application:

The update is now running again and will make sure that my installation of Acrobat 9 is up to date.

The post The Trouble with Updates – Adobe Acrobat Updater Security Error appeared first on KHKonsulting LLC.

What exactly does this mean? 

• no more technical support
• no more product updates
• no more security updates
• no more updates to support new or modified operating systems

You may think that you can live without technical support (“Hey, it’s been years since I had to call Adobe support, I have a buddy who knows this stuff…”) or product updates (“Acrobat 9 has every feature I want and need…”), but you really should consider upgrading because of the last two bullet points: Security updates are important to not compromise your system and your documents. The bad guys know that there won’t be any more updates for Acrobat and Reader 9, so if somebody finds a security leak, they can exploit this without any risk of anybody shutting down this leak. And, because Adobe has no control over what Microsoft and Apple have up their sleeves, they cannot prepare for any OS updates that can potentially harm a perfectly fine Acrobat installation.

You may not think that you need to upgrade, but you should take a long and thorough look at what you risk by running a system that is no longer supported. If you have a licensed copy of Acrobat 9, you are eligible for the upgrade discount when you upgrade to Acrobat XI. That does not make it cheap, but certainly cheaper than having to deal with just one major problem you could have avoided by running the latest version of Acrobat. 

If you are running Reader 9, there really is no reason to not upgrade: It’s a free download, so all you have to invest is some time and bandwidth. And, you are getting a bunch of new features that are well worth that time. For example, Reader XI lets you save a modified PDF file, so now you can fill in a form and save it locally, without that form being Reader enabled. You can also add text to a document, even if the document author did not enable the Typewriter tool.

So, be safe and upgrade.  

The post End of Live for Adobe Acrobat 9 Approaching Fast! appeared first on KHKonsulting LLC.

So let’s assume you create a PDF file that contains a link to another PDF file on a web server, and that second file just happens to have a space (or another special character) in it’s filename. You plead to the web master, but all begging has no effect, the filename stays the same. So, you create your link in Acrobat and test the file out with your browser and Acrobat installed and everything looks fine: Acrobat actually escapes the spaces correctly – it replaces every space with the sequence %20.

This is starting to look good – and easy. But once you test it with Reader XI, things are not looking as bright anymore. All of a sudden, there is more going on than just the replacement of spaces with %20 – we end up with the space character being replaced with %2520.

When we look up what %25 stands for in the list of URL encodings, we see that %25 is the encoding for the percentage sign: It looks like the URL got encoded twice: In the first round, the spaces got replaced with %20, and in the second round, the percentage sign (the first element of %20) got replaced with %25, so we end up with %2520 for every space in the original URL.

This is a bug in Adobe Reader, and unfortunately we need to wait for Adobe to fix this. There is however a workaround: When you turn off protected mode, the links start to work. To turn off protected mode, go to Reader’s Preferences and select the “Security (Enhanced)” category when using Reader XI, and the General category when using Reader X, then uncheck the feature “Enable Protected Mode at startup”. Restart Reader, and give it another try, it should be working now.

The post Link Trouble With Adobe Reader appeared first on KHKonsulting LLC.

Adobe published the exams and the exam guides for the new Acrobat XI Adobe Certified Expert (ACE) exams. They come in two flavors: As a brand new certification and as recertification for an existing ACE. You can schedule your test right from these pages – the new certification requires you to take the test at a testing facility, the recertification can be done online from your computer.

I just passed my recertification (my credentials are not yet published, this will take a couple of days), but here is proof that I know this stuff

Screenshot of my Acrobat ACE recertification results.

The post The Adobe Certified Expert Exam for Acrobat XI is Available appeared first on KHKonsulting LLC.

This is what Adobe has to say about this program:

With this designation, Adobe is recognizing my work at Experts-Exchange.com and AcrobatUsers.com, the talks I’ve giving about Acrobat and it’s features, and the content of this web site. This of course means some pressure for me to create more great content

Here is the list of all current ACPs.

The post Adobe Community Professional appeared first on KHKonsulting LLC.

You may ask if one small feature of Adobe Acrobat, which is comes with a ton of different features, really deserves it’s own book. The book is about stamps on the surface, the real subject of the book is almost buried in the last part of the title: Paperless workflows. Stamps are just a means to implement these workflows.

We’ve all been promised our flying cars, and the paperless office. I am still waiting for that flying car, but the paperless office can be a reality if you use the right tools, and Thom is about to introduce you to one very powerful gadget to add to your virtual tool belt. The key to using PDF stamps in such a workflow is to use not just stamps, but dynamic PDF stamps. I’ve written about them before in my post “More Interactive Dynamic Stamps in Seven Easy Steps”.

The book starts out with a very basic description of what PDF stamps are, before it moves on to describing some workflows that are based on stamps. To make things easier to understand, we do get the description of how a manual process using a static stamp would work, and that gets then contrasted with how smooth an automated workflow, based on dynamic stamps would be.

This is not just a book for the techies who would  (and can) implement such a workflow – even if you don’t know your stamp from a sticky note, the first part of the book contains a lot of useful information that would enable you to come up with ideas about how to convert your paper based processes into paperless workflows. The examples in this part should give you enough information about what’s possible with Acrobat to get your creative juices flowing. Once you have a plan, you can then hand off the implementation to somebody who cannot wait to get to the more technical parts of the book

There are enough samples in the book – starting from very basic to a fairly script intense sample in the appendix – to demonstrate the different techniques outlined in the text.

What I really appreciated is that Thom does talk about what features are documented, and which are undocumented. This allows the reader to make an educated decision about what to use and where to be cautious when the next release of Acrobat comes along.

Along the way, we are learning about a number of things that do not directly have to do with stamps like document flattening, coordinates in PDF files, storing data persistently and a few more things that broaden your JavaScript horizon. This means you are benefitting from the book even if you are not planning on implementing a paperless workflow anytime soon.

I’ve read the book in paper, but I would have loved to have a PDF version of it. There is a Kindle version available, but I spend my days in Acrobat, so having all this knowledge available in PDF and searchable via a PDF catalog would have been even better. Speaking of searching: The book does have an index, so things are easy to find.

The book was written when Acrobat X was the latest version, but everything you find in the book regarding Acrobat X should also work with Acrobat XI.

The post All About PDF Stamps appeared first on KHKonsulting LLC.

There is only an “OK” button, which closes the dialog and stops the installer.

No need to give you at this point: The reason for the error message is Gatekeeper, a new feature in Mountain Lion that limits what kind of applications can be installed without user interaction on your computer.  When configured this way, it will not allow programs that do not come from trusted sources to run. The sources that are trusted are the Mac App Store, and application that were signed with a certificate that does identify a specific developer. The key to this is in the System Preferences – bring up the System Preferences dialog and select “Security & Privacy”.

You could modify these settings temporarily, and then return to these fairly save settings, but there is an easier way around the problem:

Find the PDFtk installer that you’ve download earlier in Finder and control-click or right-click on it.

Then pick the “Open” option from the menu. This will bring up a slightly different error dialog:

There is now an “Open” button in addition to the button that closes the dialog. The message on the dialog also indicates that once we do use the “Open” button, this application will always run on this Mac, and will therefore no longer display the first error message. For a program installer that is probably not such a big deal – once the software is installed, we do no longer need to run it – but if you ever run into this error with software that is actually installed in your Applications folder, this is the way to make it run every time you double-click it.

So, just click on “Open” and let the installer do it’s job. After that, you can run PDFtk in a terminal by just typing “pdftk” or “/usr/local/bin/pdftk” if your search path is not set up to include /usr/local/bin.

The post Installing PDFtk on Mac OS X Mountain Lion appeared first on KHKonsulting LLC.

In the olden days, it was necessary to first print to a PostScript file, and then call Distiller from your program to convert that PostScript file to PDF, but for quite some time now, Adobe provides a way to specify that PDF filename by setting a registry key. The details can be found in the Acrobat SDK. Here is the link to the page that describes this registry key  process.

The registry key HKEY_CURRENT_USER\Software\Adobe\Acrobat Distiller\PrinterJobControl should already exist if you’ve printed to the Adobe PDF printer before. If it does not exist, create it before we go any further (or, just print using the Adobe PDF printer).

The documentation requires us to create a sub key – or a key value pair – where the key is the path to the application that wants to save a PDF file, and the value being the filename for the PDF file. Sounds more complicated than it actually is: To print from the WordPad application to a PDF file without begin prompted for the filename use the following key value pair:

C:\Program Files\Windows NT\Accessories\wordpad.exe = c:\MyPDFFileName.pdf

To do this in the regedit tool, navigate to the PrinterJobControl key and right-click in the pane that shows the key value pairs. Then select New>String Value – this will actually create a new string value, and will open the name up for editing – change it to C:\Program Files\Windows NT\Accessories\wordpad.exe

Once that is done, right-click on the new entry and select “Modify”. In the “Edit String” dialog set the value to c:\MyPDFFileName.pdf and click on OK.

After creating this registry key, print from WordPad and see how the file is printed without prompting for a filename. The other thing that will happen is that the key we just created gets removed. This means that this key needs to be created before every print job that needs to be saved to PDF automatically. You can see this by refreshing the view in the regedit application, but also by printing again from WordPad: This time, it will prompt for a PDF filename.

Sometimes it’s not obvious which application is actually printing – you may be running one application, but in the background it is handing control over to the application that is handling the print process. In this case, you can use the registry editor to see which application is responsible for printing. In the screen shot I’ve attached, you can see entry called “LastPDFPortFolder – wordpad.exe” – such an entry gets created every time an application prints to the Adobe PDF printer. By clearing out all sub-keys in PrinterJobControl, we can make sure we know which application was last used to print. We won’t get the full path, but just knowing the name of the executable will help to find the application.

I’ve written a small VB Script sample that will take the path to one or more Excel files on the command line, and will print these files to the default printer after setting the registry key to specify the PDF output filename.

' Set registry key to control PDF output and print an Excel
' file to PDF
' Karl Heinz Kremer - khk@khk.net - 1/18/2013 

Dim fso, exl, exlWkbk

const HKEY_CURRENT_USER = &H80000001

strComputer = "."

Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Adobe\Acrobat Distiller\PrinterJobControl"

' Just in case, create the PrinterJobControl registry key -
' it should already exist
oReg.CreateKey HKEY_CURRENT_USER,strKeyPath
Set fso = CreateObject("Scripting.FileSystemObject")
Set exl = CreateObject("Excel.Application")

exl.Visible = False

If WScript.Arguments.Count = 0 Then
WScript.Quit
Else
For A = 0 To (WScript.Arguments.Count - 1)
If ((Right(WScript.Arguments.Item(A), 3) = "xls" OR Right(WScript.Arguments.Item(A), 4) = "xlsx") AND _
fso.FileExists(WScript.Arguments.Item(A))) Then

' set the registry key
dir = fso.GetParentFolderName(WScript.Arguments.Item(A))
basename = fso.GetBaseName(WScript.Arguments.Item(A))
ext = fso.GetExtensionName(WScript.Arguments.Item(A))

strValueName = "C:\Program Files\Microsoft Office\Office14\excel.exe"
strValue = dir & "\" & basename & ".pdf"
oReg.SetStringValue HKEY_CURRENT_USER,strKeyPath,strValueName,strValue

Set exlWkbk = eXL.Workbooks.Open(WScript.Arguments.Item(A))
exlwkbk.PrintOut , , , , "Adobe PDF"
exlWkbk.Close xlDoNotSaveChanges
End If
Next
End If

eXL.Quit
Set fso = Nothing
Set exl = Nothing

You can download the script here.

To run the script, provide the full path to an Excel file on the command line:

excelprint.vbs c:\Temp\Test.xlsx

Play around with the script, see if you can implement the registry changes in a different environment (e.g. VBA or a C++ application), and most importantly, have fun!

The post Prevent the Save Dialog when Printing to the Adobe PDF Printer appeared first on KHKonsulting LLC.

I’ve talked about this in a blog post before, and given some suggestions about how to deal with the discontinuation of ADM support. Back then, Adobe had removed the header files so that no new plugins with ADM support could be compiled, but existing plug-ins that were using ADM were still working. This is no longer true: Any plug-in that was compiled with ADM enabled, will no longer work with Acrobat XI. I said “with ADM enabled” – that does not necessarily mean that ADM is actually used to generate dialogs, all that’s required for the plug-in to fail to load now is that ADM was compiled into the plug-in. For some versions of the Acrobat SDK this actually means that ADM was not explicitly disabled when the plug-in was compiled.

If your plug-in does not load in Acrobat XI due to ADM, it’s time to address this problem, there is no way around it. It might be quite a bit of work to replace an ADM based GUI, but if you want to extend the life of your plug-in, that’s what needs to be done. Let me know if I can help you with that process.

The post The End is Here – of ADM that is appeared first on KHKonsulting LLC.