Problem with hyperlinks in PDF

[etk]

My output is to PDF. I have a problem with the way that the hyperlinks are behaving in the output. With reference to the attached image, I have:
. Link 1: This is linked to Topic 1, which is in the same folder as all the topics in my project. When you hover over the link a ‘hand’ appears with a ‘W’ and a Web-type link appears as a popup.
. Link 2: This is linked to Topic 2, which is also in the same folder. When you hover over the link a ‘hand’ appears (without the ‘W’). Think link works fine – goes straight to the topic.

I have tried:
. Linking Topic 2 to Link 1 and it works OK.
. I’ve copied Topic 2 and edited the content to be the same as Topic 1. I have deleted Topic 1 and renamed the Copy of Topic 2 to Topic 1. The problem returns in the output.
. I’ve looked at the settings for both hyperlink and they seem exactly the same. Target Frame = Same Frame (and I’ve tried the other Frame types).
. The only difference I can see between Topic 1 and 2 is that Topic 1 consists only of one sentence (p tag), while Topic 2 is long. In desperation, I even put a h1 tag at the beginning of Topic 1, but it didn’t solve the problem.

Does anybody have any ideas on how to fix this problem? Has it happened to anyone else?

[doc_guy]

what is different about them in your Flare source? Can you open the topic in an external editor and post the code for the two different links? That is how I start trying to figure out why one thing behaves one way, but another similar object behaves a different way.

[etk]

Thanks Paul. I have tried that, but cannot find anything different:
This one DOESNT work:<p>At some stage during the <a href="Shift.htm" target="_self">shift</a>, Using Topic 1.
This one DOES work:<p>At some stage during the <a href="DM1_Fundamentals.htm" target="_self">shift</a>, Using Topic 2.
If I make a copy of the one that does work (Topic 2), rename it to Shift.htm (not changing the contents), then it doesnt work.
This is way beyond me!!!

[LTinker68]

You can get rid of the target=_"self" since that's the default effect. Did you verify that the file you're linking to has the same case on the text (i.e., Shift.htm and not shift.htm)? I don't know if that would really be the problem except when you're generating WebHelp and storing the output on a flavor of Apache, but maybe it's a problem with PDFs, too. I usually create hyperlinks by dragging the topic to the selected text to launch the Insert Hyperlink window so the links always match the exact file name.

[doc_guy]

I'm out of ideas on this one. I haven't noticed the behavior, but that is because I change the color of links in my PDF output to be black and I remove the underline. I expect most of my PDF users will print the guide, so links aren't as helpful to them. If they are going to be browsing the content online, they will be able to use the WebHelp version of the guide.

Long story just to say I haven't noticed the problem, but that may be because that's not how I use PDF output.

[etk]

Thanks for all your comments. It is too hard for me! I've put it to support. I'll let you know the outcome - no doubt something stupid I've done!

[etk]

The reply from support:
hyperlinks "Shift" and "Dispatcher" show the little "W" when you hover over them, because the topics where the links are pointing to are not included in your output. (they do not exist in the TOC) For this reason, when you hover over them, the "W" (Web) Adobe calls this topics via Web.

The topics are in the project, but not in the TOC. The hyperlinks that did work had topics that were included in the TOC.I cannot find anything about this in the MadCap Help on hyperlinks. I've learnt something new.

[beagley]

...because I change the color of links in my PDF output to be black and I remove the underline...

doc_guy,
Could you summarize how you do that?

I started fiddling with the Font properties of "a" in my print stylesheet, but find it daunting. I thought there might be a handy toggle for this in the "Printed Output" of the target, but didn't see it. Is it somewhere else?

-d

[doc_guy]

There is no toggle. I control it with styles in the style sheet editor.

Here is the relevant section of my style sheet:

Code: Select all

@media print
{
	a
	{
		text-decoration: none;
		color: #000000;
	}
}

[beagley]

There is no toggle. I control it with styles in the style sheet editor...

That doesn't work for me.

I'm sure I'm missing something basic... does this look right to you?

http://www.pcc.com/~douglas/RemoveBlue01.png

My goal is for links that appear in PDFs to NOT have the formatting applied by the fact that they are links. I don't want them blue and underlined, I want them to look like other text (or bold text, or whatever).

[beagley]

Okay: Interesting.

I found that when I edited the a stuff for "pseudo-link popups" it worked!

http://www.pcc.com/~douglas/RemoveBlue02.png

(I changed the "link" stuff in both of those Pseudo sections)

This seems kind of odd to me... I don't have any idea what a Pseudo class for a popup is or why it would be relevant to my PDF.

But whatever! The links in my PDFs are no longer blue and underlined.

Thanks for pointing me in the right direction.

[LTinker68]

This seems kind of odd to me... I don't have any idea what a Pseudo class for a popup is or why it would be relevant to my PDF.

Every type of hyperlink (<a>, drop-down effects, togglers, etc.) has pseudo-classes. Those control the appearance of the hyperlink in relation to the position of the cursor. If you have specified different styles for those pseudo-classes then modifying the base <a> style won't have any effect because the styles on the pseudo-classes override the styles set on the base tag. If you have never set the styles on the pseudo-classes then setting the styles on the base tag will work, because by default they'll inherit their styles from the base tag.

[beagley]

If you have never set the styles on the pseudo-classes then setting the styles on the base tag will work, because by default they'll inherit their styles from the base tag.

Okay, that makes sense. Except:

a) I'm pretty sure I've never edited those pseudo-classes before. I never much cared to worry about link color... (until I printed one of my PDFs and realized that blue underlining is quite uncool for a printed document. )

Assuming that I've messed with this before and just FORGOTTEN, then:

b) I'm not sure why my links are special "Pseudo" classes and not just plain-jane <a href=""> tags. (In the XML code, I can see that they are just ordinary <a href="">, no special style applied.)

I guess this probably has to do with Flare's special post-processing of a PDF? Somehow it must rely on those sub-pseudo-classes?

Maybe I'm dragging this question out a little, but I've noticed that one of my biggest obstacle to accepting (and loving) the Stylesheet Editor (and CSS in general) is that occasionally something like this comes up and I feel like I can never know what I'm adjusting or why. Calamity Douglas!

-d

[LTinker68]

Pseudo classes are sub-classes. If you create a custom <a> class, then that class will have its own set of pseudo classes. So you don't actually call the pseudo classes in HTML. When a browser loads the stylesheet, it looks to see what values you have specified for the pseudo classes of the specified <a> class and then changes the appearance of the link depending on where the mouse is in relation to that class. If the mouse isn't hovering over the hyperlink, then the appearance of the hyperlink is based on the "link" pseudo class. If the mouse is hovering over the link but isn't clicking the link, then it uses the appearance of the "hover" pseudo class. If you click on the link, then as you click, the "active" pseudo class determines the appearance. If you go away from the page then come back, the appearance of the link is no longer determined by the "link" pseudo class, but is instead controlled by the "visited" pseudo class. There's another pseudo class called "focus" -- that controls the appeareance of the link if you use the tab key to get to the link instead of using the mouse.

The other consideration with pseudo classes is that the order of how they're listed in the stylesheet file -- not the Stylesheet Editor -- is important. If the order is wrong, then the mouseover (hover) state is not properly shown. The order of the styles in the stylesheet file should be link, visited, focus, hover, active (LVFHA). The new phrase to remember the sequence is "Lord Vader's Former Handle Anakin". (FYI, before focus was added it used to be LOVE.) So if you're editing the styles of the pseudo classes via the Stylesheet Editor, make sure you edit them in that order so that they're added to the file in that order.

Lastly, even if you didn't specify styles for the pseudo classes, there are default appearances for each state (blue underlined initially, red underline on the hover, purple underline on the visited). If you don't want those default appearances used, then you have to modify the pseudo classes.

[MHP]

This is all very well, but...

.... how do I tell Flare to just accept whatever formatting the rest of the paragraph has? (Some of my table text is blue.)

And, I must say, there really should be a button for this in the target.

[LTinker68]

.... how do I tell Flare to just accept whatever formatting the rest of the paragraph has? (Some of my table text is blue.)

Flare can't do that itself because it's following the rules of CSS (and HTML).

You'll either need to create a new href class and set the colors for the pseudo-classes to blue and apply that class to the content, or you go with the easier option, which is to use complex selectors that change the colors of the pseudo-classes when they're the child or grandchild of a <td> tag (table cell tag). Whether it's a child or grandchild depends on if your cell content is the only thing inside the cell (child) or if your content resides in a paragraph or other tag inside the cell (grandchild). You could always create complex selectors for both situations.