TOC link with a subscript character does not work in PDF

[Guest]

Hi,

has anyone come across with this? A heading has a subscript character and when you generate a PDF, the TOC page has no link. Other TOC heading links work out just fine, but all these that have subscript, these do not.

I have used Save As PDF and selected even create named destinations for all Paragraphs. Usually the TOC works fine even if that is not selected. A link with subscript does not work in either case.

I appreciate any help with this, thanks

[Bob_Niland]

What version of FM?

What is the character, and how are you making it subscript (if not a native subscript char)? Character Format? Override?

If a Character Format, is that same tag also defined in the TOC file?

[Guest]

Version 11.0.1.382

I am using a Subscript character tag that has subscript selected in the character designer screen. I've just typed number 2 and applied the character tag. It looks fine in FM and in TOC, but page number link in TOC does not exist.

It is not an override.

All files in the book use the same tags.

[Bob_Niland]

This looks like a bug. I can reproduce it in FM7.1/Unix.

It fails on superscripts as well, and probably any Character Format applied to a paragraph picked up for TOC.

The TOC entry is working hypertext right up to the subscripted character, but nothing beyond that is.

Using a variable for the subscript doesn't help, either.

Possible work-around:

You might try using \u2082 (Unicode native subscripted 2) if that code point is populated in your font. I can't test that, as FM7.1 doesn't do Unicode.

Looking at the MIF generated was no help.
The <MTypeName `Hypertext'> tag actually ends > # end of Marker before any TOC <String begins.

Frame must be using internal rules to render each TOC line as hypertext in the PostScript.

I didn't study any Ps output because it's even less comprehensible.

When no subscript is present (normal TOC entry), there are two <String instances per line; one for the paratext and one for the page number.

When a subscript is present, each line contains three or more <String instances.

My rough guess would be that FM's internal illogic is getting confused by more than 2 <Strings.

[Guest]

I try and see whether I can use the workaround you suggested.

Thank you for your effort and impressive answer

[Bob_Niland]

And sure enough, looking at our library of manuals that have superscripted ® in headings, the TOC HT links terminate just before the ®.

If the Unicode work-around doesn't work for you (and it wouldn't for us), and having a non-subscripted 2 in the TOC is acceptable, there is another workaround, involving anchored frames, odd para tags and invisible text.

[Winfried Reng]

Hi,

The link is always terminated before any change in the character format. That's not a bug.

Therefore if you have subscript or supescript applied, the link starts at the beginning of the paragraph and ends before the character format change (sub-/superscript).

That's FrameMaker's way to define the range of a hyperlink.

See also here:

Adobe FrameMaker 12 * Set up hypertext active areas

Adobe FrameMaker 12 * Test and troubleshoot hypertext documents

A work-around would be to copy the hypertext marker from the beginning of your paragraph to the beginning of the character format change (sub-/superscript starts) and to the next beginning of the character format change (regular text).

As far as I know Rick Quatro offers a FrameScript script for this problem.

Best regards

Winfried

[Bob_Niland]

> The link is always terminated before any change in the character format. That's not a bug.

In user-authored manually-created hypertext links, sure. And in that case, we know that we have to re-apply the Marker to the various fragments of the desired text. I would not expect this behavior for a generated file where we have limited control over the auto-tagging.

> Therefore if you have subscript or superscript applied, the link starts at the beginning of the paragraph and ends before the character format change (sub-/superscript).

It's not just format changes in body <$paratext> that break this. If you so much as apply a different format to the elements on the TOC Reference Page TOC (such as making the page number a different font), that breaks the HT of the page number in the PDF.

> As far as I know Rick Quatro offers a FrameScript script for this problem.

Well, Adobe might consider this to be an Enhancement Request item, but I consider it to be a defect.

Is there anyone who would object if the TOC entries had functional full-string HT links by default? If so, Adobe could fix the problem, and have an Update tickbox to revert to legacy broken behavior.

In any case, the Unicode solution is not really a "work-around", even though I put it that way. For anything where Unicode has a glyph that you would otherwise implement as FrameRoman with a Character Format, use Unicode.

[marthab33905574]

The only way I've found to fix this is to copy the hypertext to all the text just after the sub or superscript (and then it works (though the sub or super will not be a live link. I think this is a bug in rev 12 that needs to be fixed.

[claudehowald]

It is needed to be fixed. The E-Books made out of PDF needed to be improved. And it's more important today, but the bug is in all FrameMaker-Versions (tested FM7.2 up to FM2015).