The hotspot behaviour in generated lists is user-unfriendly but works well 

for cross-references and index page numbers.  A possible fix involving 
FrameScript follows:

@       Create a new character format where all properties are set to 

@       Create a FrameScript event script that fires at the conclusion of 
a book 

@       The FrameScript would loop through all the generated paragraphs in 
the TOC 
        and apply the null character format to the entire line.

This works because, although the various character properties created by 
entry builders on the reference page would have formatted the line as you 
the only named character format on the entire line is the null format.


>Rick Quatro wrote:
>What Richard says is true, but this designed behavior is not very useful 
>generated lists. For generated lists, it would have been better to have a 

>mechanism that would ignore character property changes and make the whole 

>paragraph a link.
>>Diane Gaskill wrote:
>>> I'm not sure whetehr to call it a bug or not, but it's
>>> definitely a known problem.   Anytime there is a character
>>> font change in the text of a link in the FM file, the link
>>> ends at that point.
>>This is _neither_ a "bug" _nor_ a "known problem." To reiterate what
>>Fred and Rick have said, it's _intended_to_work_this_way_.
>>The beginning and end of a hypertext link "hotspot" have to be defined
>>_somehow_. FM programmers _could_ have required us to insert two markers
>>for each link, one for the beginning and one for the end. Instead, they
>>reasoned as follows: "Authors will certainly want to make hotspots
>>identifiable by color, underlining, or some other formatting change; so
>>we'll let the extent of the formatting change define the hotspot."
>>Just to be safe, they also terminated hotspots at the end of the pgf so
>>that you don't create a 30-page hotspot when you screw up. :-}
>>Maybe you don't like the way this works. Maybe you have some other way
>>of defining the end of a hotspot that you'd prefer (so please enlighten
>>us; I'm at a loss to think of a better alternative).
>>But this is the consciously-chosen functionality, the way it's
>>_designed_ to work. If you're not sure whether to call it a bug or not,
>>then you just don't understand.

Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
rgcombs AT gmailDOTcom


You are currently subscribed to Framers as hedley.finger at

To unsubscribe send a blank email to 
framers-unsubscribe at
or visit

Send administrative questions to lisa at Visit for more resources and info.

Reply via email to