MS Word 2007+ - can it encode hyperlinks using the PDF Action Type "Launch" instead of "URI" when publising a ".docx" file to PDF?

Short version:

• Is there any way I can make MS Word 2007 ( or newer ) encode relative file hyperlinks ( a hyperlink pointing to, e.g., another PDF file ) using the Action Type Launch instead of URI ( both types specified on page 653 of the Adobe Portable Document Format, PDF Reference, version 1.7, sixth edition - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf )? Or is the only solution to implement a post-processor that can change all of the "wrong" URI encoded file hyperlinks to their Launch equivalent?

Elaborated version:

I have two Word documents; doc1.docx and doc2.docx ( both compiled with MS Word 2007 ).

In doc1.docx I place a hyperlink to a PDF version of my second document ( doc2.pdf ) - so now I got:

I then save the doc1.docx file as both .docx and .pdf - the PDF generation is handled by the built-in PDF-publisher in MS Word 2007 using the following options:

So far so good - I then have the following folder structure:

/superuser
    - doc1.docx
    - doc1.pdf
    - doc2.docx
    - doc2.pdf

Then I open doc1.pdf with Adobe Reader X ( version 10.1.3 ) and click on the hyperlink pointing to doc2.pdf. As the link is relative I would have guessed/assumed that Adobe Reader X would simply open the target PDF file in either a separate window or in the same instance of Adobe Reader X ( depending on the option Open cross-document links in same window specified in: Edit -> Preferences -> Documents ).

However, that is not the case. Instead, Adobe Reader X resolves the hyperlink using the default browser ( in my case Google Chrome v21+ on Windows 7 x64 ) - and to be clear - this is the problem. I want Adobe Reader X ( and most of its predecessors ) to just resolve the hyperlink by opening the target PDF in another instance of Adobe Reader X ( assuming I have unchecked the Open cross-document links in same window option ). Repeating the same scenario using my ( default ) PDF reader; Sumatra PDF works as expected - Sumatra PDF opens the target PDF file in a separate window and shows me the content of doc2.pdf. So why not use Sumatra PDF then you ask? I would have loved to - however, the problem is that I am working on a project with potentially lots of end users, and I cannot assume that all of them use another PDF reader than Adobe Reader X - so, there is no other way around that figuring out what is going on with Adobe Reader X.

So to get there, I started digging.

First, by looking at the address bar in Chrome it is seen that Adobe Reader X tries to resolve doc2.pdf using the file URI scheme: file:///C:/superuser/doc2.pdf - which seems fair to me ( pasting the same URI into the Run dialog in Windows 7 causes my default PDF reader ( Sumatra PDF ) to open the file ) - but why is Adobe Reader X asking the default browser to handle the PDF?

To answer that, I continued digging. Opening doc1.pdf in notepad++ revealed that the hyperlink has been encoded using the URI Action Type ( see p. 653 and 662 in the Adobe Portable Document Format, PDF Reference, version 1.7, sixth edition - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf ):

/Type/Action/S/URI/URI(doc2.pdf)

The PDF reference ( p. 662 ) states the following about the URI Action Type:

A uniform resource identifier (URI) is a string that identifies (resolves to) a resource on the Internet—typically a file that is the destination of a hypertext link, although it can also resolve to a query or other entity.

So, what at first hand looked like a major bug in Adobe Reader X started to look like a fair implementation. At least, at this point I figured out why Adobe Reader X behaves like it does - resulting in a new question to answer: how do I proper encode a file hyperlink ( e.g. a link to doc2.pdf ) such that the resulting PDF is making Adobe Reader X handle the link itself ( instead of asking the default browser to do its job )?

To answer that I took another look at the PDF specification and found the Action Type Launch - about that type, the PDF reference states the following ( p. 659 ):

A launch action launches an application or opens or prints a document.

So by making the following change ( using notepad++ ):

Replacing:

/Type/Action/S/URI/URI(doc2.pdf)

With this:

/Type/Action/S/Launch/F(doc2.pdf)

... Adobe Reader X then resolves the link by opening doc2.pdf file in a separate window / another instance of Adobe Reader X - again assuming I have unchecked the Open cross-document links in same window option (hooray!!).

And now down to the actual / final question that I have not yet managed to solve - is there any way I can make MS Word 2007 ( or newer ) encode relative file hyperlinks ( a hyperlink pointing to, e.g., another PDF file ) using the Action Type Launch instead of URI ( both types specified on page 653 of the Adobe Portable Document Format, PDF Reference, version 1.7, sixth edition - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf )? Or is the only solution to implement some kind of post-processor application that can change all of the "wrong" URI encoded file hyperlinks to their Launch equivalent?

I know this might cause a lot of "TLDR" - but if you manage to get here I really appreciate your interest and I hope that you or someone else can point me in the right direction.

Thanks.

Solution 1:

Thank you for your excellent article. It works! Not for me at at first but then I discovered you have to turn off 'protected mode' in adobe X. I don't have this problem at all on adobe 9. It seems to me that the industry is going backwards on functionality in the name of security.

So in Adobe Reader X do:

1. Make sure open cross docs.. is unchecked. (as you said)
2. Turn off protected mode: Edit » Preferences » General
3. Search and replace /Type/Action/S/URI/URI with /Type/Action/S/Launch/F( using a suitable hex editor

There is no easy solution for what we want to do which is allow any user with only a PDF reader with no settings to bother about, to navigate around a folder.
But thanks again for all your work and the light it throws on the subject.