5 Replies Latest reply: Sep 3, 2014 12:28 PM by Error7103 RSS

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

    Error7103 Community Member
    Error7103 Sep 2, 2014 9:27 AM

      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.

      • 112 Views
      • Tags:
        • 1. Re: <Default ¶ Font> vs. </> in Variables
          Arnis Gubins CommunityMVP
          Arnis Gubins Sep 2, 2014 9:43 AM (in response to Error7103)

          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.

          • 2. Re: <Default ¶ Font> vs. </> in Variables
            Error7103 Community Member
            Error7103 Sep 2, 2014 10:15 AM (in response to Arnis Gubins)

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

            • 3. Re: <Default ¶ Font> vs. </> in Variables
              max_drawdown Community Member
              max_drawdown Sep 3, 2014 9:38 AM (in response to Error7103)

              Error7103,

              I think you have identified something important here.

              • 4. Re: <Default ¶ Font> vs. </> in Variables
                Arnis Gubins CommunityMVP
                Arnis Gubins Sep 3, 2014 9:58 AM (in response to Error7103)

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

                • 5. Re: <Default ¶ Font> vs. </> in Variables
                  Error7103 Community Member
                  Error7103 Sep 3, 2014 12:28 PM (in response to Arnis Gubins)

                  > Keep in mind that FM was designed well before structured mark-up came into common use.

                   

                  We never had these problems with troff

                  You just couldn't do some things,

                  unless you wanted to embed PostScript .

                   

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

                   

                  And given what I've trialed here, "markups" would include not just multiple nested tags in a Var, but format overrides in the surrounding text, and possibly even a named Character Format applied to the surrounding text.

                   

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

                   

                  I'm not asking for a change, as it's pretty clear that changing what </> does would seriously break documents that take advantage (intentionally or not) of how it has worked to date.

                   

                  What's needed is a new tag, perhaps </last>, which would merely undo the effect of just the most recent <whatever> tag. Or add a setting of "As-Was" to the dialogs.

                   

                  As things stand, one can craft bookend /tags for the elements on the right side of the Character Format dialog (</Underline> through </Pair_Kern>), by setting everything As-Is except for raising the specific button. But there is no un-do for the attributes on the left side (Family: through Language:); all one could do is guess at what values to return to. And even for the right side stuff, if that decoration were already active prior to the Var, you've now just turned it off.

                   

                  This is fortunately less of a problem post-FM8, with Unicode fonts having reasonable populations, as one can do many things with native characters that used to require overlay font shifts, subscripts, supers, etc. But even in the Unicode age, not all glyphs made it into the pantheon (a full set of keycaps for example, as u\20e3, KEYCAP, COMBINING ENCLOSING, can only handle one preceding character, and not a string like [Print Screen] ).