Skip to main content
Bob_Niland
Community Expert
Bob_NilandCommunity Expert
Community Expert
September 2, 2014
Answered

<Default ¶ Font> vs. </> in Variables

  • September 2, 2014
  • 1 reply
  • 664 views

Arnis: "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."

Is </> documented anywhere?

And is it identically equal to <Default ¶ Font>?

It would be nice to have a Variable construct that just means
</ChFmt> "terminate the most recent markup", rather than
<Default ¶ Font> "reset defaults for the remainder of the string to whatever para/char formats happen to be in effect."

For example, if doing an arbitrary 11/17 fraction in the pre-Unicode way as
<Superscript>11<Default ¶ Font><Symbol>\xa4<Default ¶ Font><Subscript>17
with a font override applied to the para, the denominator reverts to the Paragraph format and loses the override (yet another reason to avoid overrides, to be sure).

It is possible to create bookend Character Formats for some things, for example </Superscript> which is identical to <Superscript> except for the Superscript attribute, which is off for the </ version.

But it doesn't seem possible to do the same for a font tag like <Symbol></Symbol>. There is no undo for the font Family:, only an "As-Is" which unsurprisingly appears to do nothing.

This specific example is done much more elegantly with Unicode these days (often entirely without Character Formats), but there are doubtless other cases where a </ChFmt> tag would be useful.

    This topic has been closed for replies.
    Correct answer Arnis Gubins

    It's mentioned in the "Cross Reference Examples" section going back to at least v.7.

    "You can use the </> building block as a substitute for <Default Para Font> in cross-reference definitions."

    You can use the </> building block practically anywhere that they are used to turn off (reset) previously applied character tag building blocks: variables, indices, markers, x-refs.  (Except in auto-numbers). It's a lot easier and more succinct to enter and was often needed with the 255 character limit in some items.

    1 reply

    Arnis Gubins
    Arnis GubinsCorrect answer
    Inspiring
    September 2, 2014

    It's mentioned in the "Cross Reference Examples" section going back to at least v.7.

    "You can use the </> building block as a substitute for <Default Para Font> in cross-reference definitions."

    You can use the </> building block practically anywhere that they are used to turn off (reset) previously applied character tag building blocks: variables, indices, markers, x-refs.  (Except in auto-numbers). It's a lot easier and more succinct to enter and was often needed with the 255 character limit in some items.

    Bob_Niland
    Community Expert
    Bob_NilandCommunity ExpertAuthor
    Community Expert
    September 2, 2014

    > ... they are used to turn off (reset) ...

    That's still ambiguous, but in testing it appears that </> is indeed doing what <Default ¶ Font> does;  a major reset and not just an end-current-tag.

    > ... previously applied character tag building blocks ...

    If we think of a one or more formats applied in terms of being stacked, </> and <Default ¶ Font> are not doing a "pop"; they're doing a "flush" - and not just flushing the formats stacked up by the variable expression, but also any overrides previously applied in the para.

    > It's a lot easier and more succinct to enter and was often needed with the 255 character limit in some items.

    No argument there. I'm almost surprised that FM doesn't do it automatically, as it does for some other elements. For example, the "\xa4" above is instantly converted to a "§" upon entry.

      Arnis Gubins
      Arnis Gubins
      Inspiring
      September 3, 2014

      Keep in mind that FM was designed well before structured mark-up came into common use. The nesting of in-line tags within each other is not really recommended for Character formatting, as best practice is to create an explicit tag to cover the combined characteristics, e.g. instead of <Red><emphasis><Bold> have a <Danger> tag instead. The format reset behaviour is hard-wired in the core and tinkering with it would probably lead to unintended consequences (as previous releases have shown us when historical behaviour is "updated").

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices