Skip to main content
Known Participant
August 15, 2014
Question

Cross references not picking up character styles in source text

  • August 15, 2014
  • 2 replies
  • 1993 views

I'm getting some annoying odd behaviour with cross references in Frame 12.

I have some tables, where the paragraph style in the cell is called "Cell Body" (nothing odd there).

Quite a few of the cells only have one word in them, and that word is set to courier font with a character style (called "Code").

Then, elsewhere in the document, I am referring to this text using cross references. I am referencing the paragraph style Cell Body, and the cross reference format applied is like this "<hyperlink><$paratext><Default ¶ Font>"

"hyperlink" is another character style that makes the text go green.

So, the cross reference out to take the text from the cell (in Courier) and reproduce it, coloured green.

However for about half of these cross references, it isn't picking up the Code character style in the source text, so the cross ref is just green, no green courier.

Things are further bamboozled when I output to HTML Help.

In the CHM file, the cross refs which appear to work OK (green courier) are now just courier.
The ones which failed to pick up the courier look the same as they do in Frame (just green).

Any ideas as to what's going on?

I've tried troubleshooting by clearing the cells, reapplying the para style and default character style, then reapplying the code character style, then replacing the cross reference - which sometimes seemed to fix it but didn't always.

    This topic has been closed for replies.

    2 replies

    Arnis Gubins
    Inspiring
    August 15, 2014

    David,

    When FM picks up content for cross-refs and running headers/footers using the <$paratext> building block, only the subscript, superscript and font family properties are included with the text. If you have the Courier being used in only part of the string, then the default font for the paratag is considered first resulting in the Courier font being ignored. Likewise, the colour will also be ignored when it is part of character format within the cross-ref. You could try applying the hypertext format to the cross-ref entry itself to make it green, but I don't know how this will translate through FM's Publishing modules to HTML.

    This also is a problem when you have italic or bold as part of the cross-ref string. The attributes have to be part of the font name with the property set, so this involves a hack to the [WindowsToFrameeFontAliases] setting in the maker.ini for the particular font to allow additional formatting to be pulled into the cross-ref.

    David__DAuthor
    Known Participant
    August 18, 2014

    Thanks for the replies!

    I am aware of the 'behaviour' (some might say 'bug') of Character Formats that Error7103 describes ...  I think mine are OK in this respect, in that they don't tread on each others toes (I had to focus of the cursor off any existing text when I defined them).

    Arnis, from what you say, maybe the simplest thing is simply for me to define a new 'Courier + Green' style for those particular cross-references and use that, rather than trying to get them to inherit character styles consistently?

    (Although how that will fare with the Publish module remains to be seen...)

    Bob_Niland
    Community Expert
    Community Expert
    August 15, 2014

    > ... courier font with a character style (called "Code").

    > ... cross reference format applied is like this "<hyperlink><$paratext><Default ¶ Font>"

    What is the Font Family of the Character Format "hyperlink"? It needs to be As-Is. In fact, check all the settings for both Code and hyperlink. To safely apply multiple Character Formats to the same text, they need to differ by different attributes, with all others set to As-Is or blank.

    Although probably not involved in the problem, the trailing <Default ¶ Font> is unnecessary (and might cause other problems in other scenarios).

    Bob_Niland
    Community Expert
    Community Expert
    August 15, 2014

    Even if not the explanation for the case at hand, the case has two Character Formats applied to the same text. This usually causes problems unless some care is taken to ensure that neither format specifies conflicting values for the same attribute.

    If they do conflict, which one prevails is apt to be nearly random from one text string to the next. You could study the MIF for the file and see which is invoked last at each string.

    The error that many authors make when creating a Character Format is that the cursor is in (or even highlighting) the text they want to apply the new format to. This pre-loads every attribute in the Character Designer with the values from the current paragraph. For example, just changing the Family: or the Color: and doing an
    [Apply]

  • Store in Catalog
  • Apply to Selection
    creates a new format that has a bunch of attributes you don't want, and which will cause unexpected results (even when not applying multiple Character Formats).

    To avoid this, when creating a new Character Format, first:

    • Do a Commands: Set Window to As-Is, or
    • Click in the margin (does the same thing).