Preview.app – Killer of PDF Files

How do you feel about an application saving changes to your files without you knowing? How about if that application is not just saving harmless changes, but in the process of doing so also rewrites the file and removes important information and corrupts the document?

I would say that this behavior is unacceptable.

We are talking about the Mac OS Preview application and PDF forms. It’s a known problem that Preview gives the user the impression that a PDF form can be filled out and saved, but when such a form is then opened in a PDF viewer that is conforming to the PDF specification, the form fields are blank… The data is there, just not visible to the user because Preview “forgot” to tell the viewer that it did actually save the data, but then did not update the “appearance stream”, and it also “forgot” to set the flag that would instruct the viewer application to recreate that appearance stream. The PDF specification actually has a solution for an application that cannot update the appearance stream (section 12.7.2 Interactive Form Dictionary, the NeedAppearances entry in the forms dictionary).

Here is a 5 minute video that shows the damage Preview can do to a PDF form:

The fields that need a new appearance stream are easy to fix – all we need to do is force a redraw: There is a solution in JavaScript, but it requires to identify the problem first, and then run the script to refresh the form fields. You can find the solution with some background information on Joel Geraci’s old Adobe blog.

The problem with missing functionality (missing JavaScript actions and signature fields) are impossible to fix. The information is gone and cannot be restored.

One way to avoid this problem is by changing the Mac OS Mountain Lion (unfortunately this is not available in Lion) setting that controls if changes should be written back to modified documents without prompting the user. You can do that by opening up the Mac OS preferences, then go to the “General” category and check the box next to “Ask to keep changes when closing documents”. In my opinion, this setting should be checked by default, but Apple decided that we need the same user experience as on iOS devices, where we don’t need to worry about saving documents.

System PreferencesScreenSnapz001

There is a way to prevent these automatic saves on Mac OS X Lion (this one is not available in Mountain Lion) is to edit your TimeMachine configuration and make sure that the file gets locked after a certain time frame (unfortunately, the shortest possible time frame is one day). This way, the user has to manually unlock the file before any changes are saved to the file.

Screen SharingScreenSnapz001

Acrobat saves updates to a document with incremental updates, this way the original PDF file is protected and can still be recovered (this requires editing a binary file, and should probably be the topic of a future blog post), Preview wipes out the history of the file and therefore does not provide a way back to the original file.

The automatic saving of documents is fine for documents that can only be edited with one application (e.g. a Pages or Numbers document), but for something as common as a PDF file, especially when data gets destroyed in the process is unacceptable.

Posted in Acrobat, Apple, PDF | Tagged , , , , | Leave a comment

No Signature Required!

Adobe released the 11.0.3 update for Acrobat and Reader a few days ago, and ever since the complaints about a new green signature banner started to appear. It took me a while to figure out what’s actually going on here (especially since I had not yet seen that green bar with any of the documents I’ve opened). Here is what it looks like:

Sign here

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?

Sign2

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:

VMware FusionScreenSnapz009

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:

Registry Editor 2013 05 23 11 39 43

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.

Registry Editor 2013 05 23 11 41 24

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

Sign2 2

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.

Posted in Acrobat, PDF | Tagged , , , | 3 Comments

The Trouble with Updates – Adobe Acrobat Updater Security Error

Have you seen this “Adobe Acrobat Updater” security error on your Mac running Mountain Lion?

SafariScreenSnapz031

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”:

Activity MonitorScreenSnapz001

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:

Activity MonitorScreenSnapz002

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:

FinderScreenSnapz001

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

Posted in Acrobat, Apple, mac, PDF | Tagged , , , , , , | Leave a comment

End of Live for Adobe Acrobat 9 Approaching Fast!

This is not really “news” – Adobe announced this in June last year - but in case you’ve missed this so far, here is a reminder: Adobe is ending support for Acrobat 9 and Reader 9 on June 26th, 2013. This is just a few weeks away…

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.  

Posted in Acrobat, PDF | Tagged , , | Leave a comment

Link Trouble With Adobe Reader

Spaces in filenames for files on your web server are a bad idea… No question about that, but sometimes you don’t have control over the files you want to link to.

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.

Posted in Acrobat, PDF | Tagged , , , , | Leave a comment

The Adobe Certified Expert Exam for Acrobat XI is Available

Have you ever thought about adding the Adobe ACE Certification to your resume?

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 :)

Acrobat ACE Recertification

Screenshot of my Acrobat ACE recertification results.

Posted in Acrobat, PDF | Tagged , , | 3 Comments

Adobe Community Professional

I was very honored when I found out a few days ago that Adobe invited me into their group of Adobe Community Professionals. This is a very small and exclusive club: For the year 2013 there are 258 Adobe users worldwide across all Adobe products that have been awarded this designation, and I am one of them.

This is what Adobe has to say about this program:

The Adobe Community Professionals Program is a community based program made up of Adobe customers who share their product expertise with the world-wide Adobe community. The Adobe Community Professionals’ mission is to provide high caliber peer-to-peer communication educating and improving the product skills of Adobe customers worldwide.

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.

Community professional badge

Posted in Acrobat | Tagged , , | 2 Comments

All About PDF Stamps

Putting “All About PDF Stamps” on the cover puts the bar pretty high when you write a book about PDF Stamps… But Thom Parker clears that bar without any problems! His book “All About PDF Stamps in Acrobat & Paperless Workflows” is both a great introduction into using PDF stamps, but also a powerful guidebook to implementing complex workflow scenarios.

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.

Posted in Acrobat, Books, JavaScript, PDF, Programming | Tagged , , , , | Leave a comment

Installing PDFtk on Mac OS X Mountain Lion

One of my favorite PDF related tools is PDFtk. Some time ago I complained that it was no longer supported, but it seems that development has picked up again, and you can now find a brand new version – one that even comes with an installer for Mac OS X Mountain Lion. At least that’s what the section heading on the PDFtk page led me to believe. However, after digging a little bit deeper, I noticed that there is only one installer for Mac OS X 10.6, 10.7 and 10.8. That’s the reason why you may end up with the following error message when you try to install the package on Mountain Lion:

CoreServicesUIAgent

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”.

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.

Finder

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

CoreServicesUIAgent 3

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.

Khk  bash  85×22

Posted in PDF | Tagged , , , , , | 2 Comments

Prevent the Save Dialog when Printing to the Adobe PDF Printer

This is from the category “Frequently Asked Questions” – this time how to programmatically specify an output filename when printing to the Adobe PDF printer. As you may know, the “Adobe PDF” printer allows you to create PDF files from any application on a Windows system that can print. All you need to do is (that is, after you’ve installed Adobe Acrobat), select to print, then select the “Adobe PDF” printer, specify any job options, and print. Voila, a new PDF file is created – after the application asks you to specify the filename for the new PDF file. That is usually a good thing when you manually initiate the print operation, because then you know where your PDF file gets stored on the computer. However, if you want to programmatically create PDF files from your application (e.g. from an MS Office application using VBA), that step is quite annoying, and can ruin one’s day when trying to process 1000 files.

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.

RegistryEditor 2013 01 18 15 25 35

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!

 

Posted in Acrobat, PDF, Programming | Tagged , , , , , | 2 Comments