We have book files that contain several chapters and a glossary. We created numerous named destinations (specify named destination/jump to named destination) throughout the FM files. If we check the links in the FM files, they work fine (i.e. the linked word jumps to the correct spot). However once we PDF, it loses some (not all) of those links. Anyone have any suggestions for figuring out why or fixing the issue? To PDF, we print a PS file then distill it. We are using FM 10. There appears to be no rhyme or reason for which words work and which words don't. Any help is greatly appreciated!!
Thanks. I know how to create named destinations. And the ones we create work in FM. There is a problem when we convert to PDF - but only for a handful of links. I didn't see anything in the forum that discussed this. All of the bad links are in one particular file (but not all of the links in that file are bad), and all of our links are within one .book file (not multiple ones).
> We have book files ...
And the names that FM creates for named dests are not stable in books. As pointed out at the MicroType link:
" If a FrameMaker book is converted to PDF,
a Mnn.8.newlink. prefix is added --
nn representing the document's position in the book
(these will change as the book is updated and
some chapters are added or rearranged)."
Have you looked at the MIF for the failing destinations, to see if the names have changed?
What exactly is failing?
External URLs trying to deep link into a PDF?
You really shouldn't be using the print to ps & distill route if you have a properly setup FM installation now-a-days (btw, which version of FM?). The SaveAsPDF route works.
In your PDF setup, you must have the "Create Named Destinations for All Praragraphs" option checked. FM uses some default optimizations to post-process the postscript before distilling. One of these includes thinning out the destination targets (especially those FM thinks are unsused) to make the resulting PDFs a bit more compact. It sometimes get this step wrong. You have to force FM to leave all of the existing paragraph targets alone and add targets by using this option.
Error7103 - no, I have not looked at the MIF, but the markers in the marker pod don't appear to have different names than what we used. The error occurs in a glossary we created. We have several words within a definition that are also defined. So, we link that word in the definition to the place in the glossary where it is defined. They are all internal links. Interestingly, every single named destination we created from other FM files (within the same book) all work fine. It is only the destinations in this glossary file that work sporadically.
Arnis - thanks for the reply. We had trouble PDF'ing after switching to FM 10, and found that the print to PS worked. So, you're saying there may be an issue in our setup? We have 10.0.2.419. I would LOVE to be able to save to PDF again...we ended up with formatting issues when we did. I'll try selecting the create named destinations option and see if that helps.
Thank you both for your help.
> They are all internal links.
Then why not just use cross-references?
I've only done one glossary so far, and did it with Xrefs. In the glossary, the term and its definition are separate paragraph formats, one a run-in.
All uses of the term elsewhere in the document are xrefs to the term, by paratext, so all uses become hypertext to the glossary automatically.
You could also use sideheads or borderless tables to isolate the term for Xref.
We created cross refs as our work around. The problem with them is that we regularly update our publications based on recent changes in the law. We do so by a keyword search. The terms in a cross ref don't come up in a regular Adobe keyword search. So we have a solution that will accomplish what we want (links), but it isn't ideal. I was just trying to understand the why so we could attempt to fix the problem. Thanks!
Regarding your searches, FM has the option to search through the marker text. When you create the x-ref, FM inserts the paratext content of the target paragraph into the cross-ref marker (clipping at 255 characters minus the paratag name and the unique ID number length) that is placed in the target paragraph.
OK, thanks. We typically run our searches on the PDFs b/c we can search multiple PDFs at one time for certain keywords. But for this book, we may have to just run a FM search and search the marker text. Thanks for your help!
> We created cross refs as our work around. The problem with
> them is that we regularly update our publications ...
> We do so by a keyword search. The terms in a cross ref don't
> come up in a regular Adobe keyword search.
Searching in what application?
In my one document with an Xref Glossary, all instances of a Glossary term are found by Reader XI search - the defining instance in the Gloss, and all invocations elsewhere.
And yes, FM is weak on Glossary support. The pre-defined Marker type Glossary doesn't seem to be useful for anything.
Error 7103- We typically search in Acrobat X, though a few people may only use Reader, but I'm not sure what version. I'll try a search and see if our x-refs show up. I was under the impression that if they don't appear in a regular text search in FM, that they wouldn't show up in a PDF search. What is that saying about assuming?... Thanks!
Do you have a full version of Acrobat installed or did you use FM's PDFcreator tool that gets installed. If you had Acrobat and installed FM10 using the deafult options, then it also installs the PDFcreator (effectively a brain-dead Distiller version) which would overwrite some parts of your Acrobat installation and consequeently affecting some behaviours.
What sort of PDF'ing trouble were you having? The 10.0.2 patch fixed a lot of the PDF issues (especially related to CMYK and fonts).
I have a full version of Acrobat I'm using (Acrobat X). I think the main problem we had was with formatting. It would look fine in FM, but when PDFd, words would spill all the way over to the right side of the page (outside the set margins we had in FM). This all happened last year (or maybe 2 now!), so I'm a bit fuzzy, but I think we had a font issue, as well. Our publications use palatino linotype font, and there seemed to be an issue with that, I think.
The font spilling issue sounds like some of the problems that occurred with some fonts before the 10.0.2 patch.
You might want to try a sample through the SaveAsPDF route to see if this issue is still there. If it's sill happening, then let me know the exact font and version (OTF, TT, Type 1) that you're using
Please note that with the SaveAsPDF, you shouldn't use the CMYK option (the default in FM10) unless you're creating materials for colour press work. This will also minimize any phunnies in your PDF.
Not sure if I can reply to a forum from my e-mail, but the site appears to be down. Arnis - I just tried a save as (took off the "Convert CMYK colors to RGB" option in settings), and some of the lines still spill all the way to the right. The font we use is Palatino Linotype. I'm not sure how to find the other info you are asking for (OTF, TT, Type 1)...
If the content isn't proprietary, could you post some screen shots showing how it looks in FM and then the same location that spills over in the PDF for comparison?
If you use your Control Panel > Fonts option you should get to see all of your font families. Double-click on the Palatino Linotype one and right-click on any font within the family. Select the Properties context menu and go to the Details tab.
It will list all sorts of parameters, but the "Type" and "File Version" entries are the key ones. Itt should look something like this:
Arnis - the palatino linotype font is a TTF.
This is a screenshot of the FM document. Not sure it shows up very clearly. Maybe I need to insert it a different way?
And here is the PDF screenshot of the same page after "saving as PDF."
Sorry for all the posts! I founda second maker.ini file on my C drive (in a different location) that has the DisplayUsingPrinterMetrics set to On. I wonder if FM is using the other maker.ini file?? Not sure how I could tell which one it is using.
FrameMaker uses both versions of maker.ini. It first loads the one in
the FrameMaker installation folder to set default program preferences
for all users. Then it loads the maker.ini copy in the current user's
area. Any settings there replace the previous settings to customize the
preferences for the current user.
FM will always have at least two versions of the maker.ini on your system. The first version is in the default FM installation folder. The other is each of the Users areas. The one(s) in the Users area contain your specific settings to the FM environment. So it looks like your display settings are set properly in FM.
It really helps seeing the FM & PDF versions.
What specific version of the Palatino TTF font are you using (mine is the 5.00 as shown in the previous reply)?
In your FM paragraph designer, you seem to be using a Justified setting. What are your settings that you have in the Advanced properties of the paragraph designer for tthe Word Spacing options? I've tried duplicating your example (using a wid range of settings), but I don't seem to have any spill over issues:
In your example, it looks like only the word-spacings are messing up. The individual word lengths look to be correct when compared ot the FM file. Did you use any special spaces (i.e. non-breaking, numeric, etc.) between any of the words. (Turn on your View > Text Symbols in FM)? Are you using any special character tag, the default Emphasis tag or did you manually apply Italic (or footnote superscipt formatting) in the paragraphs that shoot over the margins?
What PDF joboptions did you use for creating the PDF?
Are you using the AdobePDF printer instance for creating the PDFs?
In Acrobat, have you checked to see if you actually have the Palatino Linotype being used in the PDF document? (Use either the File > Properties... and then look at the Font tab or use the Edit Object tool, click on the wonky text area and the right-click to get the Proprties context menu and look at the Text tab).
I am using 5.00, as well. I'm going to respond to your other questions in a separate post. Here are the settings used for one of the paragraphs where it spilled over.
You're probably using the CMYK settting in your PDF joboptions.
Here's what I get when I use that setting:
As I mentioned earlier, you really shouldn't be using that option. Use the RGB option.
[BTW, this is a bug, that may be in the font. I'll notify the Engineering team.]
OK, so before we go any further, I tried re-PDF'ing the document I showed you with the "convert cmyk to rgb" option on (i.e. it has a checkmark), and the PDF output was perfect. So, perhaps I either misunderstood the setting when you mentioned it earlier, or this is a fluke. Should that box be checked or unchecked? It appears to be working (at least on this document) with that box checked.
But to answer your above questions:
There are no consistent special spaces, formatting, or text symbols on the spillover lines. Many of them contain italicized text (done manually) or a footnote or a bullet. However, not all instances of any of these three things result in a spillover.
We typicall use the smallest file size job option.
I'm not sure if we are using the AdobePDF printer instance. I just click on "save as PDF" and I get to browse to where I want to save it, then click ok.
Yes, I just looked and palatino linotype is in there.