How can I suppress hyperlinks in PDF output?

[Centauri27]

I just discovered an issue that I never gave much thought, but can make us look pretty amateurish in the eyes of our customers... How can I suppress hyperlinks in my PDF output? We single source with Flare, producing both WebHelp and PDF targets. Naturally all the hyperlinks are suppose to work in WebHelp, but we do NOT want any of the hyperlinks enabled in the PDF (except those in the TOC, etc.). Any attempt to click a hyperlink will always produce a "File not found" error, as the referenced topic is obviously not shipped with the PDF.

I'm sure this affects everyone but I can't find a setting in Flare that turns off hyperlinking. How has everyone else handled this? The only thing I can think of is manually hunting down every hyperlink in Acrobat, but that's not feasible in a PDF spanning hundreds of pages.

Any help will be appreciated.

Thanks.
Carl

[Nita Beck]

Someone had this question a few months back. There is definitely a Flare-side solution.

Check out http://forums.madcapsoftware.com/viewto ... 10&t=14316. Especially look at dsimov's answer about applying conditions to the links. The key is the "unbind" option when the conditions are processed; by "unbinding" the hyperlinks, Flare will leave the text, but will remove the underlying links.

So that you don't have to manually condition each link, you can probably use the Find and Replace utility to add the condition to each link's coding in the source code. MAKE A BACKUP of your project before you do this, given that the find and replace might hit a lot of files and you have something to revert to if things don't go as planned.

(I know my reply here is practically shorthand, but do read dsimov's answer in that other post, and then read up on conditions and exclude action=unbind in Flare's Help system.)

Hope this helps,

[Centauri27]

Thanks for the reference, Nita. It appears that using condition tags is the best solution for now. I quake at the thought of adding conditions to thousands of links in our large help system, but I'll give it a shot. I'll also log a feature request with MadCap and see if it gets anywhere.

Carl

[NorthEast]

Thanks for the reference, Nita. It appears that using condition tags is the best solution for now. I quake at the thought of adding conditions to thousands of links in our large help system, but I'll give it a shot. I'll also log a feature request with MadCap and see if it gets anywhere.

Carl

Is there a regular pattern to these links? In the other thread you mention wanting to convert all links except those to bookmarks within the same topic. For that scenario you could use a find and replace to do the job; although I'd probably suggest using a tool like FAR HTML (it has a 30 day trial) rather than Flare's find and replace.

For example, you'd search for <a .. > tags that contain .htm (to exclude internal bookmark links), and insert MadCap:conditions="Your.Condition" MadCap:excludeAction="unbind".

[Centauri27]

Yes, there is a pattern that I can search and I was going to trudge through it using Flare's search & replace. I've never heard of FAR HTML, but it looks promising.

Thanks for the tip!

Carl

[Nita Beck]

Sorry not to have mentioned FAR HTML myself. (Thanks, Dave!) It's a great tool, especially so that you can save search expressions in a file for later reuse.

Word to the wise: Make a backup of your project before you use FAR HTML. It's powerful, and it's easy to mess something up if you're not careful. (I speak from experience!)

[NorthEast]

Sorry not to have mentioned FAR HTML myself. (Thanks, Dave!) It's a great tool, especially so that you can save search expressions in a file for later reuse.

Word to the wise: Make a backup of your project before you use FAR HTML. It's powerful, and it's easy to mess something up if you're not careful. (I speak from experience!)

Yep, definitely back-up your project first, FAR doesn't have an undo button. My experience with FAR (or any find and replace) is that it usually uncovers a few topics that don't fit the standard pattern and contain something you didn't expect. I usually need to run a few experiments before I find the right solution.

[Centauri27]

I just discovered something and I'm back to issue a mea culpa--it would appear that I lead myself in a wild goose chase and that I've raised a non-issue. I'll elaborate a bit in hopes this will spare any other chagrined help author who think they've discovered a drastic bug.

When we send out topics for review, I PDF them in one of two ways:

- for single topics, I preview the topic and then print it to PDF using any PDF driver (like PDF Factory)
- for multiple topics, I create a dummy Flare TOC & output target containing only those topics and then use that to generate a PDF

For the former, there are no live hyperlinks, so the issue does not occur. For the latter, all hyperlinks are live--even ones pointing to topics that are not present in the dummy TOC. It is these links that generate the "file not found" error when you click them. And because since the topic is not present in the PDF, the hyperlink attempts to "reach back" onto your desktop for the source file. It never occurred to me until now (after I received a response from MadCap) to check the ENTIRE generated PDF manual and lo and behold--all the hyperlinks work correctly! They all lead to the correct target topic.

I was so convinced that the hyperlinks always attempted to grab the actual source file that I never considered that the Flare PDF engine had the smarts to link them to the proper target file, provided that it is present.