Highlighted

Generated PDF file TOC entry stops being hypersensitive after text has superscripted text

New Here ,
Feb 13, 2020

Copy link to clipboard

Copied

If TOC entry text has superscripted text, any text in PDF file starting from that text is not hypersensitive. Also if TOC Reference Page format specification has font setting like
  <$paratext> <DefPageFont><$pagenum>

then the page number will not be hypersensitive. I use FM 2019 with latest patch 5. I checked some older PDF files and seems like this behaviour has been there for ever.

Adobe Community Professional
Correct answer by Bob_Niland | Adobe Community Professional

This sounds like a standard FM limitation, in that hypertext regions are delmited by either the whole paragraph, or by character format bounds. There's lots of back traffic here with more details. Here's one.

 

The modern (post FM8) solution is to avoid Character Formats in source text that feeds generated file content, such as TOC & IX. For many common sub- and superscript characters, use a font that populates the native Unicode sub/sup characters.

 

A harsher way of dealing with it is to delete the superscript or subscript Character Format from the Character Catalog in the generated files. The 'scripted chars will then appear as normal in-lines. This hack will often not work for legacy codepage fonts tho, where the glyph is entirely different without the format applied.

TOPICS
PDF output

Views

265

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Generated PDF file TOC entry stops being hypersensitive after text has superscripted text

New Here ,
Feb 13, 2020

Copy link to clipboard

Copied

If TOC entry text has superscripted text, any text in PDF file starting from that text is not hypersensitive. Also if TOC Reference Page format specification has font setting like
  <$paratext> <DefPageFont><$pagenum>

then the page number will not be hypersensitive. I use FM 2019 with latest patch 5. I checked some older PDF files and seems like this behaviour has been there for ever.

Adobe Community Professional
Correct answer by Bob_Niland | Adobe Community Professional

This sounds like a standard FM limitation, in that hypertext regions are delmited by either the whole paragraph, or by character format bounds. There's lots of back traffic here with more details. Here's one.

 

The modern (post FM8) solution is to avoid Character Formats in source text that feeds generated file content, such as TOC & IX. For many common sub- and superscript characters, use a font that populates the native Unicode sub/sup characters.

 

A harsher way of dealing with it is to delete the superscript or subscript Character Format from the Character Catalog in the generated files. The 'scripted chars will then appear as normal in-lines. This hack will often not work for legacy codepage fonts tho, where the glyph is entirely different without the format applied.

TOPICS
PDF output

Views

266

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Feb 13, 2020 0
Adobe Community Professional ,
Feb 13, 2020

Copy link to clipboard

Copied

This sounds like a standard FM limitation, in that hypertext regions are delmited by either the whole paragraph, or by character format bounds. There's lots of back traffic here with more details. Here's one.

 

The modern (post FM8) solution is to avoid Character Formats in source text that feeds generated file content, such as TOC & IX. For many common sub- and superscript characters, use a font that populates the native Unicode sub/sup characters.

 

A harsher way of dealing with it is to delete the superscript or subscript Character Format from the Character Catalog in the generated files. The 'scripted chars will then appear as normal in-lines. This hack will often not work for legacy codepage fonts tho, where the glyph is entirely different without the format applied.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 13, 2020 0
New Here ,
Feb 14, 2020

Copy link to clipboard

Copied

Thanks, using Unicode + char with superscript and removing chacter formats seems to make things work.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2020 0
Adobe Community Professional ,
Feb 14, 2020

Copy link to clipboard

Copied

Glad that resolved for you. When only a modest number of non-keyboard characters are needed, but particularly if any are not populated in your core font, consider using my Unicode-as-variable approach.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2020 0