We started using extensive Cross-refs about 5 years ago. Experienced similar
issues with some not working in pdf. At that time we turned on the links, which
generates Named Destinations all over the place, and the issue went away. We
decided to live with the bloated file size and more sluggish performance of the
pdfs.
Recently, we started doing more fancy stuff with annotations and other such in
the pdf, and the size became a huge issue with slow saves, sluggishness, etc.
Turning off the links, and optimizing the files cured that problem, but ...
some broken links reared up again. Some of these files are 50 pages of many
column tables in small print, so are most likely generating 50,000 or so named
destinations with the links on. This is not acceptable.
So we did some serious research and discovered the following:
When Frame populates Frame generated files, such as TOCs, Indexes, Lists of,
etc. it generates a Named Destination for its internal use for those
elements/paragraphs called in the generated files. This is permanently stored
in the Frame file. This is why the hyperlink markers in the generated files
always work, regardless of the links setting in the pdf setup.
We painfully discovered that if you manually create a hypertext marker of the
type used for generated files:
openObjectId {filename}:2 {UniqueID}
and point to a UniqueID that is called by a generated file the link works in
pdf, and if not called it does not work in pdf. Works great in Frame. As a test
I generated a file containing only the element/paratag type (Para in this
case), and recreated the pdf. The broken links for that element//paratag type
then worked, but but broken links for others not in the generate did not.
We use the FDK to create a highlight report, and build links manually to point
to the associated content. We now know why some work and some don't if the
links setting is off. Some were in content called by generates and some were
not.
We also had issues with some, but not all cross-refs when the links setting was
off. Here we discovered that if you point to another file in a Frame book, and
DO NOT UPDATE THE FRAME BOOK before you create the pdf, those cross-refs do not
work in the pdf, although they are OK in Frame. So it would seem that Frame
also creates and stores named destinations for cross-refs when you update the
book.
I surmise that after you complete your cross-ref work if you update the book
prior to pdf creation they will work with the link setting off. Same thing
should hold true for a single file. Updated the file before you do the pdf.
Others may have more insight on this. We are now researching methods to create
named destinations for our manually inserted hypertext markers without
resorting to turning on the links setting.
