IBM ELO PUB Jazz 7.1 - TOC Behavior with Multiple Heading Styles
- Predefined style "Title" works well , appears in TOC
- Imported styles from .dotx (Heading_1 to Heading_9) do not appear
- Manually created styles (Title_1 to Title_9) also fail to appear
- "Title" is always included in TOC
- Only Text elements trigger TOC entries
- toc item level = 5 works correctly
- heading level offset is honored
Unexplained behaviors
- Heading_01 and similar styles ignored despite valid setup
- No way to inspect or set Style Type (Paragraph vs. Character) in Document Studio
- No feedback when TOC fails to include styles
- Style inclusion seems tied to internal typing logic
Summary
- Only "Title" style consistently appears in TOC. All other styles fail despite correct configuration.
- We suspect internal style typing is the root cause.
- How can we mark your own styles as being TOC-effective?
- What criteria does PUB check to include styles in the TOC?
- What else should we check?
- Are there known issues with TOC in Jazz 7.1?
- Any workaround or diagnostic tools?
- Where can we find deeper documentation on TOC and style handling?
4 answers
- TOC Code doesn't help -> the Styles like Heading_1, Heading_2 and more are not visible in TOC
- e.g. TOC Code = TOC \t "Heading_1,1,Heading_2,2,Title_01,1" \h \z \u
- Style is defined correct, also the Style Type = Paragraph
- Style Type = Paragraph in dta-Template.xml result in a Style Type = Character in generated HTML-Doc (<span>Heading_2</span>)
It looks like an issue in processing Styles for TOC in Jazz 7.1 ELO PUB
Thank you, Davyd, for your timely and well-considered reply. We will use this approach to verify the behavior.
Based on our experience with ELO PUB 7.1, we have encountered behavior that appears inconsistent and counterintuitive in non-Word workflows.
In our dta file, we manually assign level-specific paragraph styles, such as Heading_1 or Heading_2, to each doc-chapter. These style names are not used arbitrarily. Both the document block (doc-chapter) and the associated style are configured to reflect a specific structural level, ensuring semantic clarity and consistent styling throughout our documentation.
We do not rely on automatic style detection and we do not use Word templates with mapped styles. Our entire workflow is based on dta and DSX-Launcher.
Despite these level-aware configurations, ELO PUB renders the styles in the HTML output as inline elements rather than semantic block-level headings. As a result, the table of contents generation fails to recognize these entries, even though their levels are explicitly defined in both style metadata and content markup.
From our perspective, this behavior reduces the reliability of structured styling and compromises TOC usability in non-Word scenarios. At the very least, we would expect consistent handling of configured levels during export, especially when defined explicitly in both style and content logic.
If this behavior is intentional, we kindly request clear documentation of this limitation. Otherwise, we hope IBM considers enhancing this aspect of the export mechanism in future releases.
Comments
Thanks for your valuable input, Davyd - we have to review your suggestions thoroughly.
In our setup, we have observed that only the predefined "Title" style appears in the Table of Contents (TOC). Even though we have created custom styles and properly classified them as heading styles within the Word template, they are not picked up by PUB for TOC generation.
These styles were manually defined in the template (not imported), and we have ensured they are semantically consistent. However, PUB seems to ignore them in the TOC logic.
So far, we have only tested this behavior with dta/dsx templates, and we have not yet had a chance to explore it with dotx templates via Launcher. We would be very interested to know if there is any internal mapping mechanism or limitation that restricts TOC recognition to specific styles.
Is there a documented mapping or a known way to register custom styles so PUB includes them in the TOC structure?
You: ... then you must use the Word default names of "Heading 1", "Heading 2", "Heading 3", "Heading 4", "Heading 5", "Heading 6"
-
Styles with spaces are not accepted in dta Document Studio
Comments
Sorry regarding new answer. It was not possible to comment your post, only my anwer. Think I've got the hang of it now
Based on your response, Davyd, we might interpret that IBM PUB does not currently implement a mechanism to fully translate well-defined styles from dta templates into functional Word styles - for example, the "Paragraph" style seems to be lost in translation.
It also seems that TOC generation may only work reliably when using Word-based templates via the dsx Launcher, as PUB appears to rely on Word's native style mapping rather than its own internal logic.
Thanks again, Davyd. That makes perfect sense now. Given our use case — printing risk content with header, footer and TOC from Jazz EWM — requiring dotx templates added complexity, as dta/dsx workflows are more flexible in our setup. We’ve therefore handled TOC manually so far. Considering these constraints, we’ve opted to control TOC visibility and layout via scoped pattern logic and manual style management.
You: "there are quite a few articles out there that will give you lots of help."
- I'm still searching ;-)
We configured TOC generation in IBM ELO PUB Jazz 7.1 using Word-based heading styles. Styles like Heading_1 and Heading_2 work when applied to Text elements.
However, the TOC code editor in Document Studio rewrites valid field code incorrectly. For example:
Expected:
TOC \t "Heading_1,1,Heading_2,2,Heading_3,3,Heading_4,4" \h \z \u
After opening the editor:
TOC \t "Heading_11Heading_22Heading_33Heading_44" \h \z \u
This breaks TOC output silently.
Workaround: Edit the TOC code in an external editor and paste it into the Property dialog—not the editor window.
Would be helpful if this behavior could be clarified or addressed.