FM10 variables: does <Default Paragraph Font> still clear formatting?

[MarkLeh]

I'm trying to build variables in FM10 that I can copy then paste "cleanly". Have tried variables of the form

<Default Paragraph Font>text<Default Paragraph Font> and

<Default Paragraph Font>text

but when I paste either of these and continue typing, the following text has the style of the originally-copied variable, not the style of the para into which I pasted the variable.

Any ideas re getting FM10 to do what I want?

Can anyone confirm that this method works in FM7 (I've uninstalled FM7 so can't test it) but doesn't work in FM10?

[Arnis Gubins]

It sounds like you're picking up a characer format that is applied externally to the variable so any attempts at resetting within the variable won't apply (even when correctly applied). If you need the formatting for the variable, then apply it in the variable definition. Do NOT apply a character format to an inserted variable - very bad mojo.

If the variable is already defined in the document, you can also use the ctrl+0 method to quickly insert it.

[MarkLeh]

OK, just for the record... 

In FM10 (10.0.2.419), I've  created a variable <Default ¶ Font>VarText and inserted it into a Heading. Then I copied it from the heading and pasted it into a Body para where its appearance changed to that of Body -- all good so far. But then text I type directly after the pasted variable has the Heading appearance -- erk.

And I've just done the same thing in FM7 and the following text takes on Body appearance, which is what I was expecting.

So this means that in FM10 we can't use Find/Change > By Pasting to insert clean variables like we could in FM7.

Yet another FM10 disappointment.

[Arnis Gubins]

Mark,

In rebutal, I just checked back with FM8, FM7.2 and FM6 and the behaviour is all the same as in FM10. If you copy and paste a variable from another para format, the pasted version of the variable carries along the formatting of the context that you copied it from - exactly as would happen for any text copied from the same paratag. The setting of the <Default ¶ Font> at the start of the variable does turn off the formatting for the variable text that follows, however the variable container still has the formatting of the source.

It doesn't matter that what's pasted is a variable or not. When you copy any content from one paragraph to another, you pick up the formatting from the location that you copied from. If you try a Paste Special > Text, you will strip the formatting, but in the case of a variable, you will deposit the contents of the variable and not the variable itself.

Here's the same behaviour in FM7.2 with the "variable" in red so that it stands out:

Note: if you use the arrow key to move over a space immediately after inserting (in any version) you won't get the formatting that comes along for the ride. If you place your cursor immediately at the end of the variable and check the format settings in the Character Designer, you will still see the source formatting that came along for the ride.

The bullet-proof way to quickly insert variables is to use the ctrl+0 and type-ahead of the variable name (this shows in the Status bar as you type the variable name). Use variable naming techniques that will get you the unique string in 2-3 characters, then it's only ever a few keystrokes away.

In the Find/Change by Pasting situation, you would need to copy the variable from a similar context. Note: this applies to anything that you've put on the clipboard, including text and not just variables.

[MarkLeh]

Yes Arnis, you're right. And thanks for all your input.

I now amend the procedure I gave above. When saying "pasting", I was actually using the Alt+click method of transferring the variable from the Heading para to the Body para -- I've been assuming for years that this is equivalent to Copying and Pasting, which I now see it's not because...

When I Alt+click the variable from the Heading para to the Body para a "truly clean" variable is transferred in FM7.1 but not in FM10.

I slightly revise my FM10 disappointment.   🙂

Thanks again Arnis.

[Arnis Gubins]

Mark,

I just tested the "Quick Copy" method (insert cursor and then hold the alt key while highlighting some content) with various versions of FM and it seems like this change in behaviour occurred with FM8 (i.e. the introduction of unicode support). It's hard to say whether this could be considered a bug.

[Bob_Niland]

Just to be sure, you are actually using:

<Default ¶ Font>

and not

<Default Paragraph Font>

AG: Do NOT apply a character format to an inserted variable - very bad mojo.

I've lately run into the need to do just that (or something like it). I have some review-edition-only text that appears on cover master pages. In the text string is an empty checkbox (a dingbat), done with a Variable. I don't have an instance handy, but the definition is something like:

Name: char.dingbat.checkbox.empty

Def: <Dingbat>\x##<Default ¶ Font>

The entire string gets a "Review" character format applied (which consists of just a unique color controlled by Color Views).

When I set one of these up, it looks great initially, but after the first save and re-open, the check box has lost its color. I have to apply either just the color as a local override, or the char format to the Var instance, to get it to stick.

If the <Default ¶ Font> was the culprint, you'd expect the text following the var to lose it's color.

I haven't studied any MIF on this yet, because it's a trivial problem. (And this is FM7.1/Unix, should that matter).

[Arnis Gubins]

One can also use the </> building block to specify turning off a character format.

@Error: A variable is an independent container, so when you apply a character format to the container, that then applies to everything within it. There really is no explicit need for the terminating <Default ¶ Font> in the variable definition in your case, as any formatting is not allowed to bleed outside of the variable container. The termination is only required when you need a formatting change within the varaible definition itself.

My reference to this being a sub-optimal practice is that there can be all sorts of unintended consequences to applying the formatting externally to the variable, as the OP seems to have stumbled across.

[Bob_Niland]

AG: > A variable is an independent container, so when you apply a character format to the container, that then applies to everything within it. There really is no explicit need for the terminating <Default ¶ Font> in the variable definition in your case, as any formatting is not allowed to bleed outside of the variable container. The termination is only required when you need a formatting change within the variable definition itself.

Thanks for that tip. We'll cease using the redundant terminating tag.

> My reference to this being a sub-optimal practice is that there can be all sorts of unintended consequences to applying the formatting externally to the variable, as the OP seems to have stumbled across.

In my case, I've determined that the trailing <Default ¶ Font> was not the reason why some Variable-defined characters were randomly losing externally-applied Character Formats.

It was because the Character Format used in the Var. Def. was itself defective. The Character Format wasn't setting As-Is for all attributes except those of interest. In the particular case at hand the external ChFmt "Review", which just set a color, was conflicting with the fact that the ChFmt "Dingbats" was needlessly declaring "Black".

This results in a conflict, and apparently which format prevails is merely a function of what sequence order Frame uses when rendering, and apparently that varies in different edit scenarios.