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

adobe-readermicrosoft wordpdf

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:

Properties of the <code>doc2.pdf</code> hyperlink in <code>doc1.docx</code>

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:

MS Word 2007 PDF Publish Properties

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.

Best Answer

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.