Cross references not picking up character styles in source text

[David__D]

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.

[Bob_Niland]

> ... 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]

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).

[David__D]

Error7103 wrote:

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.

Actually, it turned out that my "hyperlink" format had managed to get its Font Family set to "Arial" rather than "As Is".  I've fixed this (made a new blank doc, made a correct "hyperlink" character format in it, and imported that into my document, overwriting the Arial-contaminated 'hyperlink' format) - although knowing FrameMaker, probably the old contaminated one is still getting applied as "format overrides" ...

it doesn't seem to have fixed the errant behaviour yet.

I also tried making a new Cross Reference Format that explicitly asks for 'hyperlink' and 'Code' styles ( "<hyperlink><Code><$paratext>" ) but that doesn't seem to have cured things yet either.

[max_drawdown]

Error7103

Error7103 wrote:

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

Hmmm, that's news to me. I have been using that from an abundance of caution. Maybe "abundance of ignorance" is apt.

Assuming that a more appropriate thread does not exist, will you mention an example or two of scenarios where this causes a problem? I'm about to head into multi-channel in FM12, so the cleaner my "core code" in FM12, the better.

Best regards,

[David__D]

I was also surprised to hear that about Default Font...

In any case, none of the advice here has solved my issue yet

It seems to act up "Update Book" refreshes the formatting on any cross references,

so as a workaround I'm going round and manually reapplying formatting to some of my cross refs after updating the book... this manual formatting is then retained in the CHM output.

I remain completely baffled why some seemingly identical items in table cells are ending up differingly formatted as cross refs - I can't find any difference in the source. It's almost like something you'd see in MS Word!

[Arnis_Gubins]

The turning off of properties using the <Default ¶ Font> tag is probably a habit that goes back to some buggy behaviour in very early editions of FM where occasionally a specified character format would spill out of an x-ref (or was it a variable?). FWIW, it's easier and more convenient to use </>  instead. However, nowadays this isn't necessary at the end of a x-ref, variable or whatever - FM does this by default very reliably.

@David,

Using two character tags in-line together (a la <hyperlink><Code>) is asking for trouble. IIRC, FM doesn't re-apply these in order on an update and depending upon how they are defined (and what is set to AsIs), the outer one usually wins. You should create a new combined tag (e.g. <Code_hyperlink>) that as all of the properties that you require.

Also, x-ref formatting may behave differently in the new Publishing modules depending upon if it defined as part of the x-ref format or applied to the x-ref after the fact [I haven't investigated this yet, but keep in mind that the RH formatting markup model differs from the FM one and the Publish routines come from RH].

[David__D]

Arnis Gubins wrote:

Using two character tags in-line together (a la <hyperlink><Code>) is asking for trouble. IIRC, FM doesn't re-apply these in order on an update and depending upon how they are defined (and what is set to AsIs), the outer one usually wins. .

So why does the blimmin' dialog invite me to do precisely that, by providing me with a list of all the character styles I have, and allowing me to select as many of them as I like??? /sulks/   Indeed, if Frame still shipped with a printed user guide instead of  stupid "optimised for viewing on iPhones" online webhelp nonsense, I suspect I might very well be able to find an example in the manual of using multiple character styles in that dialog!  If it doesn't want you to use more than one, why doesn't it grey out after you add the first one? /sighs/  The concept is called "cascading styles", it's a fundamental web paradigm! And it works in the main body text - why not in Xrefs!

Also, I have been very scrupulous to keep my character styles orthogonal so none of their AsIs's mash each other up.
But, rant over, I shall follow your splendid suggestion for a "Code Hyperlink" style.

Arnis Gubins wrote:

Also, x-ref formatting may behave differently in the new Publishing modules depending upon ....

...Depending on how badly designed and buggy this new Frame12 feature is, I should say!   The Publish module should not randomly stop behaving in a WYSIWIG manner in completely undocumented fashion just because Adobe couldn't be bothered to code it properly.  /sighs/

Frankly, for my current project, I've given up trying to jump through hoops for Publish - I'm concentrating on getting the Frame source right and assuming these quirks will be fixed in Frame 13 (or 14, depending on how superstitious they are). Because if I put in ad hoc workarounds for them in Frame 12, I (or a colleague) will only have to undo them later when they're fixed, and by then we'll all have forgotten what the original problem was.

[Arnis_Gubins]

David wrote:

So why does the blimmin' dialog invite me to do precisely that, by providing me with a list of all the character styles I have, and allowing me to select as many of them as I like???

Probably because one can use different character tags around different components, e.g. "<Hyperlink><$paratext></> on <emphasis>page <$pagenum></>" 

David wrote:

...Depending on how badly designed and buggy this new Frame12 feature is, I should say!   The Publish module should not randomly stop behaving in a WYSIWIG manner in completely undocumented fashion just because Adobe couldn't be bothered to code it properly.  /sighs/

Frankly, for my current project, I've given up trying to jump through hoops for Publish - I'm concentrating on getting the Frame source right and assuming these quirks will be fixed in Frame 13 (or 14, depending on how superstitious they are). Because if I put in ad hoc workarounds for them in Frame 12, I (or a colleague) will only have to undo them later when they're fixed, and by then we'll all have forgotten what the original problem was.

Have you ever known a first version component to behave perfectly [regardless of what the marketing material wants you to think ]?  I think it's commendable that Adobe [India] is listening to what the users are asking for (instead of just leaving everything in RoboHelp and saying use the TCS). But as you indicate, not-ready for prime time implementations should be tweaked a lot more before being let loose upon an unsuspecting user. [One really wonders what their QC routines actually test... Also, perhaps trying to stick to an 18-month release cycle may not be the best plan given their limited resources.]

[max_drawdown]

@Arnis_Gubbins

Thanks for the follow-up.

Best,

[max_drawdown]

Error7103

I see you mention this:

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

Per lower on this thread, that's news to me. I have been using that from an abundance of caution. Maybe "abundance of ignorance" is apt.

Assuming that a more appropriate thread does not exist, will you mention an example or two of scenarios where this causes a problem? I'm about to head into multi-channel in FM12, so the cleaner my "core code" in FM12, the better.

Best regards

[Bob_Niland]

> ... will you mention an example or two of scenarios where this causes a problem?

Not for a few days, as I don't have any examples at my current location.

[Bob_Niland]

> ... will you mention an example or two of scenarios where this causes a problem?

For those stumbling onto this thread in the future, see:
<Default ¶ Font> vs. </> in Variables

The problem with ending a Variable expression with <Default ¶ Font> (or its clone </>) is that it's not just unnecessary. </> performs a more severe reset of formats than just letting the variable expression end. It also turns off any format override in effect prior to the var, and may turn off any Character Format in effect. Although the end of the variable is supposed to reliably return the formatting to whatever it was pre-variable, I think I have seen lingering effects in FM7. I haven't tested extensively in any later FM.

But within a string created by a var, I have definitely witnessed <Default ¶ Font> turning off a pre-var override.

So you want, to the extent possible, to avoid using <Default ¶ Font> in Variables at all. For some format attributes, like <Superscript>, if you need to exit SS before the end of the variable, craft a </Superscript> that just turns off SS. If what you need, for example, is a font Family: change early in the var, you're largely out of luck unless you have certain knowledge of what font to revert to.

[David__D]

Playing with the Frame 12.0.3 Update this morning,

it looks like one of the bug fixes in it have fixed some of the problems described on this thread (i.e. the Publish module refuse to behave in a WYSIWYG manner when I make CHMs).

Hard to be sure though, as I was baffled as to what the cause was so I'm not 100% sure the solution matches

[Arnis_Gubins]

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__D]

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...)