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