Skip to main content
F
frmage
Known Participant
May 5, 2008
Question

Stray bullets in TOC

  • May 5, 2008
  • 6 replies
  • 717 views
We use two parallel templates with 3 heading levels, one with numbered headings and the other unnumbered. The headings are used in the TOC. <br /><br />Numbered headings work fine, but if the section preceding a heading in the unnumbered variant includes bulleted or numbered paragraphs, the bullet or number appears in front of the following TOC entry. For example<br /> Heading 1<br /> text<br /> <bullet> text<br /> Heading 2<br /> text<br /> <bullet> text<br /> Heading 3<br /> ...<br />generates a TOC with <br /> Heading 1<br /> <bullet> Heading 2<br /> <bullet> Heading 3<br /><br />Can't seem to be able to get rid of this. <br />Margaret Bower had a thread last August with a similar mess-up for page numbering, but that was apparently resolved by using different numbering streams for different purposes. Although our problem looks as though it might be related, playing with numbering/bulleting streams doesn't help.<br /><br />The templates for numbered and unnumbered heading variants are identical except that numbering has been removed from <br /><br />What's going on? And more importantly, how can we fix it (except by manually editing the TOC after generation)?<br /><br />The problem applies to both versions 7 and 8.
    This topic has been closed for replies.

    6 replies

    F
    frmageAuthor
    Known Participant
    May 7, 2008
    OK, Peter - i was guessing at how the carry-over effect was being generated, you seem to be better informed... From your description I would agree that it is certainly confusing behaviour and dangerously close to bug status.

    I haven't tried using conditional text - I think the fix we are using will work adequately. We use a full template for the numbered variant and a "mini-template" carrying only the changed properties for the unnumbered variant (which is less common). That way we can implement multiple template variants without too much risk of divergent evolution between templates.

    Quite honestly, I am wary of using advanced functions like conditional text. My experience of FM simply doesn't inspire enough confidence - badly constructed, buggy, inconsistent, counter-intuitive even in the basic functions. If they can't get simple things like find-replace right (try entering a text in the Change field and then clicking Change multiple times and see what happens!), then expectations of more complicated functions are low indeed.

    /Francis
    P
    peter minneapolis
    Participating Frequently
    May 7, 2008
    Hi, Francis:

    If I understand your description correctly, if the <$paranumonly> building block for an unnumbered paragraph format displays a carried-over value from a numbered paragraph format in a generated TOC, I'd say it is a bug.

    <$paranumonly> should extract and display the value of the paragraph it refers to. The "carryover effect" is achieved with notation that identifies a different paragraph format, in square brackets like this: <$paranumonly[different_paragraph_format_name]> extracts and displays the value of the most-recent instance of a paragraph tagged with different_paragraph_format_name, if there is one in the current file, and if it has the autonumbered property, and the and a value exists.

    Your solution uses the correct specification, but it seems that your former method invoked a confusing FM behavior, if not a bug.

    Have you tried using conditional text settings for the two template types, to show/hide the appropriate paragraphs in the reference-page TOC specification?

    HTH

    Regards,

    Peter Gold
    KnowHow ProServices
    F
    frmageAuthor
    Known Participant
    May 6, 2008
    Hi Peter
    I thought it was a bug too at first. But then I realized that if variables like <$paranumonly> didn't keep their values, it would be difficult to implement things like variable page headers and footers using system variables.

    So I see it as more of a design limitation. A full solution would need two kinds of system variable, one that keeps its value until the next change and one that is reset on the next occurrence of a paragraph which lacks the property in question.

    In my particular case it was easy to redefine the TOC entries on the reference pages so that the unnumbered template doesn't use the <$paranumonly> variable.

    /Francis
    P
    peter minneapolis
    Participating Frequently
    May 6, 2008
    This sounds like a bug in both TOC and x-refs. If you agree, please file a bug report at:

    http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

    Regards,

    Peter Gold
    KnowHow ProServices
    F
    FieryPantone
    Legend
    May 6, 2008
    Thanks for posting the answer as well as the question, Francis; makes the forum a good resource. I'd run into the same bullet behaviour in cross-refs and tracked it down, but not seen it in a ToC.
    F
    frmageAuthor
    Known Participant
    May 5, 2008
    Solved our own problem!
    The unnumbered template was created from the numbered template, and the TOC entries on the reference pages still had <$paranumonly> items in the format definitions. It would seem that the value of <$paranumonly> is set to a bullet by a bulleted paragraph but is not reset to empty by a non-bulleted paragraph. So the bullet value will carry over as the value of <$paranumonly> until the next paragraph that uses autonumbering.
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices