Answer: Re: Odd bug printing FM to PDF

[hedley.fin...@myob.com]

All:

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 
null.

@   Create a FrameScript event script that fires at the conclusion of 
a book 
generate/update.

@   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 
the 
entry builders on the reference page would have formatted the line as you 
want, 
the only named character format on the entire line is the null format.

Regards,
Hedley



>Rick Quatro wrote:
>
>What Richard says is true, but this designed behavior is not very useful 
for 
>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.
>
>Rick
>
>>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
303-223-5111
--
rgcombs AT gmailDOTcom
303-777-0436
--

___


You are currently subscribed to Framers as hedley.finger at myob.com.

To unsubscribe send a blank email to 
framers-unsubscribe at lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/hedley.finger%40myob.com


Send administrative questions to lisa at frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

Answer: Re: Odd bug printing FM to PDF

[Diane Gaskill]

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.  And of the text that includes the 
link does not completely define the destination, the link does not work in he 
PDF file.  It does not matter whether the link is automatically generated or 
manually created.  I've worked around that by manually inserting a link on the 
far side of the font change, but I don't know how to do it automatically.  
Shlomo might have something on his site about that, or email him directly at 
shlomo at microtype.com and ask.   

Hope this helps,

Diane Gaskill 


-Original Message-
>From: Rick Quatro 
>Sent: Jan 10, 2006 5:06 PM
>To: Joe Malin , framers at FrameUsers.com
>Subject: Re: Odd bug printing FM to PDF
>
>As Fred says, this is designed behavior. See Chapter 19, "Hypertext and 
>View-Only Documents" of the User Guide, particularly the "Preparing areas 
>for becoming active" section. Reading this won't necessarily solve your 
>problem, but at least you will understand what is happening.
>
>Rick Quatro
>Carmen Publishing
>585-659-8267
>www.frameexpert.com
>
>Hi!
>
>Seems like I've found an odd bug with hyperlinks from generated files
>when I "print" an unstructured FM book from FM 7.1 to PDF.
>
>I have found that when I print a FM book to PDF, the page numbers in the
>TOC and index are automatically converted to hyperlinks in the PDF. The
>text of the entry is also converted to a hyperlink. Thus, when I move my
>cursor over the entry or page number in the PDF file, it turns from a
>hand to a pointer.
>
>However, if the entry's text is not in the default paragraph format for
>the entry, this automatic conversion doesn't happen.
>
>For example, if I go to the TOC reference page and change (for example)
>the line for the chapter entries so that the page number has a "bold"
>character format, the entry is converted to a hyperlink but not the page
>number itself.
>
>So if I have the line
>
><$paranum><$paratext><$pagenum>
>
>(this line has the paragraph tag ChapterTitleTOC)
>
>and I select "<$pagenum>" and apply a character tag (say "Bold"), then
>the chapter entries in the TOC look fine, but the page numbers are
>converted to hyperlinks in the PDF. The *chapter* number and text are
>hyperlinks but not the *page* number.
>
>This also happens if I surround <$pagenum> with a  tag, for
>example
>
><$paranum><$paratext><$pagenum>
>
>This also happens in index entries.
>
>Anyone seen this before?
>
>Joe
>TuVox, Inc.
>19050 Pruneridge Avenue Suite 150, Cupertino, CA 95014-0715
>
>Joe Malin
>Technical Writer
>(408)625.1623
>jmalin at tuvox.com
>www.tuvox.com <http://www.tuvox.com/>
>The views expressed in this document are those of the sender, and do not
>necessarily reflect those of TuVox, Inc.
>
>___
>
>
>You are currently subscribed to Framers as dgcaller at earthlink.net.
>
>To unsubscribe send a blank email to 
>framers-unsubscribe at lists.frameusers.com
>or visit 
>http://lists.frameusers.com/mailman/options/framers/dgcaller%40earthlink.net
>
>Send administrative questions to lisa at frameusers.com. Visit
>http://www.frameusers.com/ for more resources and info.

Answer: Re: Odd bug printing FM to PDF

[Combs, Richard]

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 


--
Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
--
rgcombs AT gmailDOTcom
303-777-0436
--

Answer: Re: Odd bug printing FM to PDF

[Rick Quatro]

What Richard says is true, but this designed behavior is not very useful for 
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.

Rick

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


--
Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
--
rgcombs AT gmailDOTcom
303-777-0436
--

Answer: Re: Odd bug printing FM to PDF

[Joe Malin]

I don't particularly care one way or another. I see that it's not a bug
by Adobe's definition, and I can live with that.

Joe 

| -Original Message-
| From: framers-bounces+jmalin=tuvox.com at lists.frameusers.com 
| [mailto:framers-bounces+jmalin=tuvox.com at lists.frameusers.com]
|  On Behalf Of Combs, Richard
| Sent: Wednesday, January 11, 2006 10:22 AM
| To: framers at frameusers.com
| Subject: RE: Answer: Re: Odd bug printing FM to PDF
| 
| 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.
| 

Answer: Re: Odd bug printing FM to PDF

[Combs, Richard]

Rick Quatro wrote:

> What Richard says is true, but this designed behavior is not 
> very useful for 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.

OK, granted -- maybe they should have implemented a different mechanism
for generated lists, instead of reusing the hypertext marker
functionality. But they didn't, preferrring to keep things simple.
 

Hey, forgive the rant -- I'm just a bit over-caffeinated. ;-) 

Richard


--
Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
--
rgcombs AT gmailDOTcom
303-777-0436
--

Answer: Re: Odd bug printing FM to PDF

[Jeremy H. Griffith]

On Wed, 11 Jan 2006 13:57:36 -0500, "Rick Quatro"  
wrote:

>What Richard says is true, but this designed behavior is not very useful for 
>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.

I agree.  Can't change Frame, but in Mif2Go output we have
a property that does that, "ParaLink", which can be assigned
to para formats.  It's especially handy for Frame-generated
TOCs being converted to some form of HTML or XML, since the
entire entry is a link regardless of char format usage.

-- Jeremy H. Griffith, at Omni Systems Inc.
http://www.omsys.com/

Answer: Re: Odd bug printing FM to PDF

[Rick Quatro]

For those interested, there is a possible FrameScript solution that would 
solve the problem in PDFs. A script could go through the TOC and look for 
lines with character property changes. It would duplicate the first 
Hypertext marker and insert it whereever there is a character property 
change. The end result would be multiple links in the paragraph, but since 
they would butt together, it wouldn't be a problem in the resulting PDF. The 
script could be triggered automatically whenever the TOC is generated.

Rick Quatro
Carmen Publishing
585-659-8267
www.frameexpert.com


> On Wed, 11 Jan 2006 13:57:36 -0500, "Rick Quatro" 
> 
> wrote:
>
>>What Richard says is true, but this designed behavior is not very useful 
>>for
>>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.
>
> I agree.  Can't change Frame, but in Mif2Go output we have
> a property that does that, "ParaLink", which can be assigned
> to para formats.  It's especially handy for Frame-generated
> TOCs being converted to some form of HTML or XML, since the
> entire entry is a link regardless of char format usage.
>
> -- Jeremy H. Griffith, at Omni Systems Inc.
>http://www.omsys.com/
> ___

Odd bug printing FM to PDF

[Joe Malin]

Hi!

Seems like I've found an odd bug with hyperlinks from generated files
when I "print" an unstructured FM book from FM 7.1 to PDF.

I have found that when I print a FM book to PDF, the page numbers in the
TOC and index are automatically converted to hyperlinks in the PDF. The
text of the entry is also converted to a hyperlink. Thus, when I move my
cursor over the entry or page number in the PDF file, it turns from a
hand to a pointer.

However, if the entry's text is not in the default paragraph format for
the entry, this automatic conversion doesn't happen.

For example, if I go to the TOC reference page and change (for example)
the line for the chapter entries so that the page number has a "bold"
character format, the entry is converted to a hyperlink but not the page
number itself. 

So if I have the line

<$paranum><$paratext><$pagenum>

(this line has the paragraph tag ChapterTitleTOC)

and I select "<$pagenum>" and apply a character tag (say "Bold"), then
the chapter entries in the TOC look fine, but the page numbers are
converted to hyperlinks in the PDF. The *chapter* number and text are
hyperlinks but not the *page* number.

This also happens if I surround <$pagenum> with a  tag, for
example

<$paranum><$paratext><$pagenum>

This also happens in index entries.

Anyone seen this before?

Joe


TuVox, Inc.


19050 Pruneridge Avenue Suite 150, Cupertino, CA 95014-0715

Joe Malin   
Technical Writer
(408)625.1623   
jmalin at tuvox.com 
www.tuvox.com    
The views expressed in this document are those of the sender, and do not
necessarily reflect those of TuVox, Inc.

Odd bug printing FM to PDF

[Ridder, Fred]

It's not a bug. It is behaving as designed. The active area (hot spot)
for a hyperlink extends from the hypertext marker until either a change
in formatting or a paragraph break is encountered. It works that way 
when you manually insert a hyperlink, and it works that way when
FrameMaker inserts a hyperlink for you.

My opinions only; I don't speak for Intel.
Fred Ridder (fred dot ridder at intel dot com)
Intel
Parsippany, NJ



-Original Message-
From: framers-bounces+fred.ridder=intel@lists.frameusers.com
[mailto:framers-bounces+fred.ridder=intel.com at lists.frameusers.com] On
Behalf Of Joe Malin
Sent: Tuesday, January 10, 2006 6:47 PM
To: framers at FrameUsers.com
Subject: Odd bug printing FM to PDF

Hi!

Seems like I've found an odd bug with hyperlinks from generated files
when I "print" an unstructured FM book from FM 7.1 to PDF.

I have found that when I print a FM book to PDF, the page numbers in the
TOC and index are automatically converted to hyperlinks in the PDF. The
text of the entry is also converted to a hyperlink. Thus, when I move my
cursor over the entry or page number in the PDF file, it turns from a
hand to a pointer.

However, if the entry's text is not in the default paragraph format for
the entry, this automatic conversion doesn't happen.

For example, if I go to the TOC reference page and change (for example)
the line for the chapter entries so that the page number has a "bold"
character format, the entry is converted to a hyperlink but not the page
number itself. 

So if I have the line

<$paranum><$paratext><$pagenum>

(this line has the paragraph tag ChapterTitleTOC)

and I select "<$pagenum>" and apply a character tag (say "Bold"), then
the chapter entries in the TOC look fine, but the page numbers are
converted to hyperlinks in the PDF. The *chapter* number and text are
hyperlinks but not the *page* number.

This also happens if I surround <$pagenum> with a  tag, for
example

<$paranum><$paratext><$pagenum>

This also happens in index entries.

Anyone seen this before?

Joe


TuVox, Inc.


19050 Pruneridge Avenue Suite 150, Cupertino, CA 95014-0715

Joe Malin   
Technical Writer
(408)625.1623   
jmalin at tuvox.com 
www.tuvox.com <http://www.tuvox.com/>   
The views expressed in this document are those of the sender, and do not
necessarily reflect those of TuVox, Inc.
___


You are currently subscribed to Framers as fred.ridder at intel.com.

To unsubscribe send a blank email to 
framers-unsubscribe at lists.frameusers.com
or visit
http://lists.frameusers.com/mailman/options/framers/fred.ridder%40intel.
com

Send administrative questions to lisa at frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

Odd bug printing FM to PDF

[Rick Quatro]

As Fred says, this is designed behavior. See Chapter 19, "Hypertext and 
View-Only Documents" of the User Guide, particularly the "Preparing areas 
for becoming active" section. Reading this won't necessarily solve your 
problem, but at least you will understand what is happening.

Rick Quatro
Carmen Publishing
585-659-8267
www.frameexpert.com

Hi!

Seems like I've found an odd bug with hyperlinks from generated files
when I "print" an unstructured FM book from FM 7.1 to PDF.

I have found that when I print a FM book to PDF, the page numbers in the
TOC and index are automatically converted to hyperlinks in the PDF. The
text of the entry is also converted to a hyperlink. Thus, when I move my
cursor over the entry or page number in the PDF file, it turns from a
hand to a pointer.

However, if the entry's text is not in the default paragraph format for
the entry, this automatic conversion doesn't happen.

For example, if I go to the TOC reference page and change (for example)
the line for the chapter entries so that the page number has a "bold"
character format, the entry is converted to a hyperlink but not the page
number itself.

So if I have the line

<$paranum><$paratext><$pagenum>

(this line has the paragraph tag ChapterTitleTOC)

and I select "<$pagenum>" and apply a character tag (say "Bold"), then
the chapter entries in the TOC look fine, but the page numbers are
converted to hyperlinks in the PDF. The *chapter* number and text are
hyperlinks but not the *page* number.

This also happens if I surround <$pagenum> with a  tag, for
example

<$paranum><$paratext><$pagenum>

This also happens in index entries.

Anyone seen this before?

Joe
TuVox, Inc.
19050 Pruneridge Avenue Suite 150, Cupertino, CA 95014-0715

Joe Malin
Technical Writer
(408)625.1623
jmalin at tuvox.com
www.tuvox.com 
The views expressed in this document are those of the sender, and do not
necessarily reflect those of TuVox, Inc.