I have 2 Micrsoft Word files, File1 has a Hyperlink that points to the Path of File2 except the file extension is pdf. I use Adobe Acrobat Standard Version and convert both Word files to pdf. Clicking on the Hyperlink in File1 will now find the File2.pdf. However, if I move these files to a different folder the hyperlink no longer works.
How can I get my hyperlinks to reference a generic folder structure instead of referencing the full path?
Our users will create a document with hyperlinks on their development server and then we want to move those documents to our various production jobsite servers, but the path always points back to the development server.
Thanks,
RLGilby
Hyperlink stops working when directory structure is moved
2010-12-03 08:24:03
My Product Information:
Acrobat Standard 8.0, Windows
Acrobat Standard 8.0, Windows
2010-12-03 09:25:32
#2
George,
When I click on the properties of the Hyperlink in the Word doc it shows up as "../05/05-01.pdf".
Which is what I want, and that is what I want the converted pdf link to look like.
But when you click on the link in the word document it shows the full path:
"file///\\servername\userfolder\subfolder\05\05-pdf.
And then when I bring up Adobe Acrobat Standard version 8 and convert the Word document to a pdf document the path for that hyperlink is "F:\userfolder\subfolder\05\05-pdf". \\servername is mapped to our F drive.
However, when we move this out to production the servername will change and the folder structure will change going from the F drive to our I drive with different foldernames on I.
So to me Addobe is not keeping it as "../05/05-01.pdf". If it was then everything would work fine.
RLGilby
When I click on the properties of the Hyperlink in the Word doc it shows up as "../05/05-01.pdf".
Which is what I want, and that is what I want the converted pdf link to look like.
But when you click on the link in the word document it shows the full path:
"file///\\servername\userfolder\subfolder\05\05-pdf.
And then when I bring up Adobe Acrobat Standard version 8 and convert the Word document to a pdf document the path for that hyperlink is "F:\userfolder\subfolder\05\05-pdf". \\servername is mapped to our F drive.
However, when we move this out to production the servername will change and the folder structure will change going from the F drive to our I drive with different foldernames on I.
So to me Addobe is not keeping it as "../05/05-01.pdf". If it was then everything would work fine.
RLGilby
2010-12-03 21:08:16
#3
Hi,
Applications that support "link" functionality such as browsers, Adobe Reader, Acrobat, Word, etc do keep/register the author's link syntax (path).
When this path has passage through directories/sub-directories then these same "directional markers" must be present in whatever location we place copies of the source/target files.
You've created a link, in Word that reflects the physical presence of specific directories/sub-directories.
All of these are under a parent directory that also has physical existence.
The link is from a source file up and out of some sub-directory (let's name it "sourceFiles_here").
After stepping "up" out of sub-directory "sourceFiles_here" we are in the root of "subfolder".
From "subfolder" we must step down into sub-directory "05".
In sub-directory "05" we locate file "05-01.pdf".
Having locating this file we ask the OS to inform the governing application for *.pdf to open and render the file.
This is all in context of the mapped drive "F".
When source and target files are copied to another mapped drive success of any links from source to target is predicated upon an unalterable major premise.
This is that, in the new location (mapped drive "I") precisely the same parent directory and child sub-directories exist (e.g., the same name (and character case (if unix/linux)) are physically present.
Once you set a specific link path the applications (Word, Acrobat, whatever) do not / cannot change the path's syntax.
If the links are to function then "I" must contain the correct topography of parent/child directories.
A "parent" ("subfolder").
A "child" under "subfolder" ("sourceFiles_here").
A "child" under "subfolder" ("05").
Whatever directory layout existed in "F" (or some staging zone) *must* be present in production ("I").
This maintains congruence of the relative path(s) between source and target.
Observe this for webspace URIs or network space UNCs (Novell, Unix, Active Directories).
How Adobe Reader / Acrobat processes links (in context of the "host" box - local machine/server) is discussed in the PDF References that came before the PDF ISO standard (32000-1) as well as in the ISO standard.
However, again, this is contingent upon having a directory/sub-directory layout and naming that preserves the relative locations of source/target PDFs.
Not an issue if the link path (syntax) never passes through any directories/sub-directories.
(In staging, work out of directory "bucket-o-files" and in production, drop stuff into directory "another bucket-o-files").
Applications that support "link" functionality such as browsers, Adobe Reader, Acrobat, Word, etc do keep/register the author's link syntax (path).
When this path has passage through directories/sub-directories then these same "directional markers" must be present in whatever location we place copies of the source/target files.
You've created a link, in Word that reflects the physical presence of specific directories/sub-directories.
All of these are under a parent directory that also has physical existence.
The link is from a source file up and out of some sub-directory (let's name it "sourceFiles_here").
After stepping "up" out of sub-directory "sourceFiles_here" we are in the root of "subfolder".
From "subfolder" we must step down into sub-directory "05".
In sub-directory "05" we locate file "05-01.pdf".
Having locating this file we ask the OS to inform the governing application for *.pdf to open and render the file.
This is all in context of the mapped drive "F".
When source and target files are copied to another mapped drive success of any links from source to target is predicated upon an unalterable major premise.
This is that, in the new location (mapped drive "I") precisely the same parent directory and child sub-directories exist (e.g., the same name (and character case (if unix/linux)) are physically present.
Once you set a specific link path the applications (Word, Acrobat, whatever) do not / cannot change the path's syntax.
If the links are to function then "I" must contain the correct topography of parent/child directories.
A "parent" ("subfolder").
A "child" under "subfolder" ("sourceFiles_here").
A "child" under "subfolder" ("05").
Whatever directory layout existed in "F" (or some staging zone) *must* be present in production ("I").
This maintains congruence of the relative path(s) between source and target.
Observe this for webspace URIs or network space UNCs (Novell, Unix, Active Directories).
How Adobe Reader / Acrobat processes links (in context of the "host" box - local machine/server) is discussed in the PDF References that came before the PDF ISO standard (32000-1) as well as in the ISO standard.
However, again, this is contingent upon having a directory/sub-directory layout and naming that preserves the relative locations of source/target PDFs.
Not an issue if the link path (syntax) never passes through any directories/sub-directories.
(In staging, work out of directory "bucket-o-files" and in production, drop stuff into directory "another bucket-o-files").
2010-12-07 06:32:02
#4
Are you telling me that if I have two word documents (Doc1 and Doc2). Doc1 has a Hyperlink to Doc2. I create PDFs from Adobe Acrobat Standard 8 on our development file server (\\DevFS01). I can view the new PDFs correctly where they were originally created from, but if I move them to our 5 production jobsite fileservers (\\Jobsite1, \\Jobsite2, \\Jobsite3, \\Jobsite4, \\Jobsite5), the hyperlink from the Doc1 PDF is not going to work because it is still pointing to \\DevFS01?
I can't believe this software could be so restricting, that means for every different location these pdf's moved to we are going to have recalculate all the hypelinks every time?
I can't believe this software could be so restricting, that means for every different location these pdf's moved to we are going to have recalculate all the hypelinks every time?
2010-12-07 22:36:43
#5
The issue is how applications are to resolve UNC or URI/URL link paths.
It is incumbent upon the content author to have a firm understanding of the details associated with these.
Provided the path through directories/sub-directories is valid (they are present along with the source/target files) then one can relocate to another server, another desktop or laptop computer, or CD/DVD.
A Word Hyperlink, through some directories or directly to an adjacent file has a target file (with its specific file extension) established by the content author.
If the link goes to "anyfile.DOC" then "anyfile.DOC" is the target of the link in the output PDF of the source *.doc file. There's no wizard's wand in applications to change the target file set by the content author.
A link in file01.doc to file02.pdf will still point to file01.pdf when file01.doc goes to PDF.
A link path between two adjacent files passes through no directories/folders. Such can be relocated and, provided they stay adjacent, the link works.
BUT, again, when relocation of the PDFs occurs does the new location contain the folders the link path passes up through and/or down through?
If not, the link is "broken".
An output PDF in the staging zone lives at:
[serverName or mapped drive]\eLIB\LB\[facName]\[facMaster]\[unitNo]\[LBdoc]\chapterXX.pdf
and has a link with the following link path:
File: [serverName or mapped drive]\eLIB\LB\[facName]\[facMaster]\[unitNo]\[docsFigs]\cadFig.pdf
The two PDFs can be relocated to a production location.
However, both the staging and the production locations must have a common "parent" directory/sub-directory layout.
[DevFS01], [Jobsite1], etc. must have commonality of directory structure at some point in the network share.
Where that might be is determined by the size an topography of the source/staging PDF document collection.
Bottom line is that at some point a "parent" directory and associated sub-directories placed by a content author in a link path must exist in the relocated location.
True in webspace. True in network space. Has not changed in the 10+ years of providing and maintaining gigabytes of PDFs in both (webspace on a Unix server, network space in Novell and now AD) as well as production of OSM for distribution.
Early Acrobat 7 had issues with resolving the 'host' location of PDFs when relocating the files.
This was resolved by the Acrobat update process.
Not an issue for Acrobat 8, 9, or X.
How an agent is to process links in a PDF is discussed in Section 7.11 (File Specifications) of ISO 32000-1.
http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
A number of sites provide good discussion of the how-to/why-for associated with UNC links.
W3C provides a similar discussion for URI/URL. More detailed discussions are in the relevant RFCs.
Be well...
It is incumbent upon the content author to have a firm understanding of the details associated with these.
Provided the path through directories/sub-directories is valid (they are present along with the source/target files) then one can relocate to another server, another desktop or laptop computer, or CD/DVD.
A Word Hyperlink, through some directories or directly to an adjacent file has a target file (with its specific file extension) established by the content author.
If the link goes to "anyfile.DOC" then "anyfile.DOC" is the target of the link in the output PDF of the source *.doc file. There's no wizard's wand in applications to change the target file set by the content author.
A link in file01.doc to file02.pdf will still point to file01.pdf when file01.doc goes to PDF.
A link path between two adjacent files passes through no directories/folders. Such can be relocated and, provided they stay adjacent, the link works.
BUT, again, when relocation of the PDFs occurs does the new location contain the folders the link path passes up through and/or down through?
If not, the link is "broken".
An output PDF in the staging zone lives at:
[serverName or mapped drive]\eLIB\LB\[facName]\[facMaster]\[unitNo]\[LBdoc]\chapterXX.pdf
and has a link with the following link path:
File: [serverName or mapped drive]\eLIB\LB\[facName]\[facMaster]\[unitNo]\[docsFigs]\cadFig.pdf
The two PDFs can be relocated to a production location.
However, both the staging and the production locations must have a common "parent" directory/sub-directory layout.
[DevFS01], [Jobsite1], etc. must have commonality of directory structure at some point in the network share.
Where that might be is determined by the size an topography of the source/staging PDF document collection.
Bottom line is that at some point a "parent" directory and associated sub-directories placed by a content author in a link path must exist in the relocated location.
True in webspace. True in network space. Has not changed in the 10+ years of providing and maintaining gigabytes of PDFs in both (webspace on a Unix server, network space in Novell and now AD) as well as production of OSM for distribution.
Early Acrobat 7 had issues with resolving the 'host' location of PDFs when relocating the files.
This was resolved by the Acrobat update process.
Not an issue for Acrobat 8, 9, or X.
How an agent is to process links in a PDF is discussed in Section 7.11 (File Specifications) of ISO 32000-1.
http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
A number of sites provide good discussion of the how-to/why-for associated with UNC links.
W3C provides a similar discussion for URI/URL. More detailed discussions are in the relevant RFCs.
Be well...
George Kaiser