Linking has a filename size restriction?

How long are the links? Can you provide a sample link destination path?

Also, what version of Word are you using?

Word 2003 with SP3

Below is one of the longest pathnames

K:\Intranet PDF files of standard controlled documents\AV RES LV Laverton\Work instructions\MF Manufacturing\Reaction Stream 1\Recovery\Ammonia Refrigeration On Line Operation & Trouble Shooting Guide.pdfIf I link manually using the Link Tool it is not a problem. Currently I am converting using the PDFmaker, then using the edit function on the Link Tool to fix up those links that do not work

I tried your link with Acrobat 9, Word 2003 SP3. Seems to work fine
Word document:
https://share.acrobat.com/adc/document.do?docid=aa1ee0d4-ea49-4ff4-b685-3debc555a564
PDF:
https://share.acrobat.com/adc/document.do?docid=048ad21b-95d2-4408-b3b3-57d0e2018088

I couldn't get it to work with K drive as that didn't exist on my system. Once I changed it to C drive it started working. So do ensure that the destination that you are selecting is accessible from the machine where you care creating the PDF.

Are your links created in similar fashion in Word?

Unfortunately I can't get the files in your links to open.

We have a long weekend coming up so I will try to work out what the pattern is regarding filename size next week with our IT person. The links are all consistent, work well in the Word document and work well in the pdf document but won't if the filename is not too long (end up with a document containing some links working and others not).

Thanks for your thoughts

Update to issue: after some more investigation, the problem still appears to be location based. If the source word document is in a fairly high-level directory (eg K:\dir1\dir2\sourcedoc.doc) and the pdf is output to the same directory, the hyperlinks on the pdf are funtional.
If, however, the source document is much further down (in the current situation we're looking at K:\dir1\dir2\dir3\dir4\sourcedoc.doc) the previously stated issue arises, with longer links (pointing to documents which are also around 5 levels of directory hierarchy down) being nonfunctional.
If the source document is in the first instance (2 directory levels) and is output to the second, the links function. If the converse is carried out, they do not.
The current workaround is to create the pdf in a higher level directory to retain the links, then to edit the footer in the resulting pdf which is then moved to the desired final location.
Is in fact a character limit for hyperlinks, or are my observations coincidental?

Have you tried creating relative links instead of absolute links to avoid issues?
For more infomation on absolute vs. relative links visit:
http://support.microsoft.com/kb/291182#

Also, if you create relative links turn off the following option in MSWord, "Update automatic links at open" in the General tab of the Options menu. This causes Word to add the document's current path to all relative links when you open the document, which may break your relative links. This is important if you move the documents.

Well I do now have a satisfactory workaround to solve the problem. It is to create all the hyperlinks as absolute hyperlinks (for each Word document under Properties, Summary, put an x in Hyperlink Base). This way all the hyperlinks are reliably converted.

The bug that remains is that when Adobe processes relative hyperlinks if the file being pdfed has many characters in its directory path, it will only successfully create hyperlinks to files that have few (say about 10) characters in their filename i.e. a pdf document will end up with some hyperlinks working, and others hyperlinking to exactly the same directory not working (unless one shortens their filename). Alternatively, if the file being pdfed has few characters in its directory path, then all relative hyperlinks work.

I am suspecting that it is a problem in the PDFMaker's macro

cwalters,
I tried the steps and it seems to work for me.
The drive letter 'k:' in your address path is a physical drive on your machine or is it a folder/drive on some other machine mapped on to your system?
Can you share a simple word doc and its pdf.

Hi cwalters,
In your second post you provided an example of a representative link path to the target file.
Is the use of the space character a literal representation?
User agents that process links (URI/URL or UNC) can/do exhibit awkward behavior at times when
the link to process contains space characters.
Having experienced similar awkwardness with the ampersand character, I avoid its use as well.
Use of reserved characters can be a problem. Any "ooops" vis-a-vis" escaping or unescaping these can goober a link.

I've found the "best practice" (for me, at least) is to hew to the fundamentals discussed in these RFCs:
RFC3986, RFC1738, RFC2368, & RFC2396; followed by application of what I've noodled out about links in PDF and how they are processed by Reader/Acrobat.Worth noting is that, tucked away in Adobe's articles (KB, TechNotes), the SDK documentation, the Adobe
PDF References & the ISO-32000 document, there are a fair number of pointers to the reliance on the RFCs for establishing how PDF "links" (file specification) function.While perhaps not pertinent to your environment, it is good to know how character case is dealt with if you author in Windows on the desktop but deploy to UNIX, Linux, Novell, &/or Microsoft Active Directories.There may be an upper bound on a link path's character count. I've not hit it; but, I keep my "nesting" to a shallower "depth" by design. Should there be such an upper bound it would be good know its value, eh?

Clearly, you've got a frustating situation. For myself, thank you for sharing the workaround.
That goes on my "just in case" shelf .Be well...

Cause of the problem seems now to better understood.

Thanks to all who contributed

While my files were approx 170 characters in length, in the relative hyperlink conversion process the filename ends up exceeding 256 characters. This is due to:
1. replacing the mapped k: with the actual path name (AVS001\global); and
2. spaces in the filename being replaced with %20; and
3. some extra characters being added in the background (for some reason) to
record the position of the Word file that the pdf is being created from - I say
this because if the Word file is not deep in the directory then there is no
hyperlinking problem. NOTE that the problem does not depend on the
directory depth of the pdf file that has been created (and this does not
seem logical)

If this reasoning is correct, then that is why decreasing the length of the filename that the pdf links to fixes the problem. Also creating pdfs as absolute hyperlinks works because the above point 3 becomes redundant.