FM9: Cross refs lost when building a PDF (Terri Schultz)

[Rick Quatro]

You may want to consider TimeSavers from MicroType
(http://www.microtype.com). It has an "Unbloat" feature which removes all
unused named destinations during the distilling process. You check Create
Named Destinations for All Elements and Paragraphs in the PDF Setup dialog
box; then TimeSavers transparently removes any that aren't in use. Please
let me know if you have any questions or comments. Thank you very much.

Rick

Rick Quatro
Carmen Publishing Inc.
585-283-5045
585-219-8959 fax
rick at frameexpert.com
http://www.frameexpert.com



-----Original Message-----
From: framers-bounces at lists.frameusers.com
[mailto:framers-bounces at lists.frameusers.com] On Behalf Of Oran Petersen
Sent: Wednesday, May 16, 2012 11:22 PM
To: FrameMaker List
Subject: RE: FM9: Cross refs lost when building a PDF (Terri Schultz)


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. 
_______________________________________________