Known Participant

Answered

Include icon graphics in table of contents (TOC)?

Forum|Forum|11 years ago
July 22, 2014
1 reply
920 views

Question

Is it possible to have icons (i.e. inline anchored frames) automatically appear in the TOC?

(We translate into 15+ languages, so adding the graphics manually to the TOC after it's generated isn't really a viable option.)

Scenario

In our manuals, we include a troubleshooting section explaining what different warning symbol icons mean. (Kind of like the various check engine lights you see in cars.) It'd be nice to show the actual icons in the TOC, to hopefully make that info a little easier to find.

We do include the icons in the actual headings in the book using shrink-wrapped anchored frames, but each anchored frame gets replaced with a space in the auto-generated TOC. (Which is what we would want in most cases, just not this particular instance.)

Specs

We're working in unstructured FM 11.

Thanks in advance,

Jason Nichols

This topic has been closed for replies.

Correct answer Bob_Niland

If you are willing to have a separate paragraph format for each variation of icon, you might be able to use the Frame Above property of each corresponding xxxTOC tag to bring in its icon, using the negative-space Frame-Above hack that Arnis described lately at:

Are circled numbered steps possible?

This is going to pollute the Paragraph Catalog of course.

I would be tempted instead to use some font rendering tool to convert your icons to character glyphs in Unicode Private Use Area E000-F8FF*. Then the icons are just text brought in with each heading. Note: switching Character Formats in a heading breaks the automatic hypertext in the TOC. See:
Page Number color in TOC

The link termination problem could be avoided by using an open license Unicode text font that is similar to your preferred heading font, and adding the icon glyphs to it in Private Use Area. Then there is no character format change in the affected TOC entries. Of course, turning your icons into font glyphs presumes you have vector art for them that is easily converted to outlines, otherwise it's going to be a major effort.

_____

* I would avoid Private Use Areas A or B, due to being on Planes 15 and 16 (larger than 32-bit code points).

Bob_Niland

Correct answer

Community Expert

If you are willing to have a separate paragraph format for each variation of icon, you might be able to use the Frame Above property of each corresponding xxxTOC tag to bring in its icon, using the negative-space Frame-Above hack that Arnis described lately at:

Are circled numbered steps possible?

This is going to pollute the Paragraph Catalog of course.

I would be tempted instead to use some font rendering tool to convert your icons to character glyphs in Unicode Private Use Area E000-F8FF*. Then the icons are just text brought in with each heading. Note: switching Character Formats in a heading breaks the automatic hypertext in the TOC. See:
Page Number color in TOC

The link termination problem could be avoided by using an open license Unicode text font that is similar to your preferred heading font, and adding the icon glyphs to it in Private Use Area. Then there is no character format change in the affected TOC entries. Of course, turning your icons into font glyphs presumes you have vector art for them that is easily converted to outlines, otherwise it's going to be a major effort.

_____

* I would avoid Private Use Areas A or B, due to being on Planes 15 and 16 (larger than 32-bit code points).

Jason_Nichols2Author

Known Participant

Interesting, thank you.

I agree the 2nd option is more elegant, and we do have vector art for the icons. But, changing fonts is always problematic for us. So few fonts seem to support all the many symbols and characters we need for all the possible 25 or so languages we might translate a manual to. (I wonder if Adobe's new Source Han Sans font would work?)

Also, there are only 4 icons we need to define, so we may be able to live with the extra paragraph styles if we go with the first option.

I have a little research and testing to do, but both these options sound do-able. Many thanks!

Jason Nichols

Bob_Niland

Community Expert

> So few fonts seem to support all the many symbols and characters we

> need for all the possible 25 or so languages we might translate a manual to.

Well, you only need glyphs used in Headings, but I suppose if some of your languages are non-roman, it's still a challenge.

Perhaps you could petition the Unicode Consortium to add your icons to Unicode, then sit back and wait for the foundries to incorporate them.
Actually, this might not work even if it didn't take years - as the new glyphs would be likely to be added above the BMP (Basic Multilingual Plane), and I'm not actually sure that FM fully supports more than the BMP (e.g. \u123456 notation in dialogs). FM uses UTF8 internally, which can encode any Unicode code point or string, but I don't seem to have any fonts on my FM9 machine that go above FFFF, so I couldn't, for example, test \u1f527 (wrench).

>> ... due to being on Planes 15 and 16 (larger than 32-bit code points).

And a correction to my earlier remark about the Supplemental Private Use Areas. Make that "... larger than 16-bit" (4 octet).

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded