Link to home
Start Free TrialLog in
Avatar of kasperEH
kasperEHFlag for Denmark

asked on

All document variables are in bold, even though I mark them as not bold in the template

I am working on a Word 2010 template (.dot). It contains some document variables that are automatically filled out by an external program. Even though I specifically mark them as not bold, when I open a document filled with values from the external program, then they are in bold. I think it started after a refresh of all fields, where there was a lot of "Error! No document variable supplied" texts for empty variables. These were in bold, but even after I change them to not bold, then they still become bold when I open a document based on the template.
Avatar of AmazingValor


Did you try selecting the entire text and changing the font. It might be the font.

Try copying/cutting it and pasting it in another text supportive software like Notepad etc.

Then copying it back.
Avatar of kasperEH


Thank you for comment, AmazingValor. The font is Arial, and it has to be that font. If I copy the text to Notepad and back, then the document variables will disappear.
Avatar of GrahamSkan
If it can be edited to remove any confidential test, I suggest that you attach the document here.
Otherwise,  following on from AmazingValor's suggestion, try selecting all the text and toggling the Bold setting (leaving it Off)
Here is a version of the template, where I have removed most of the text, but the problem is still there.
I tried in the template to mark everything, set it as not bold, then save, but the problem is still there. I think it has something to do with the fact that I ran a refresh on all document variables which gave the Error! No document variable supplied message on those variables not set. The reason I  refreshed was to show values changed by a macro.
I selected column 2 of the table and reset the bold attribute for that column, Then I set it back again for column 3 in rows 5 & 6. Finally I selected the three fields after the table and reset them back to unbolded.

Because Word 2016 redirects the save location for a template, I have saved it as a document, so you will have to rename it to make it a template again
Thank you, but when I rename to .dot, a new document based on the template still has the document variables in bold. I'm using Word 2010, not sure if it makes a difference.
The field codes in your template all include the \* MERGEFORMAT switch (which gets applied by default unless you turn off the "Preserve formatting during updates" checkbox in the Field dialog box).

When this switch is included, the field code result will take on whatever formatting of the previous result or had been applied when the field code was inserted.

If you toggle the field code visibility (press Alt-F9), you can see that the codes appear not bold — yet the results (or an error message) are set in bold because bold has been applied to the cell's formatting.

I recommend you remove the full \* MERGEFORMAT switch (you can use Find and Replace when the field codes are visible) and select the cells to turn off any bold. You can then manage the field code results more directly (and predictably).

A better way to manage the formatting of a field code result is to apply the format to the first character of the field code. This will ensure that the result uses that formatting even if the rest of the field code or text that includes it is set with different formatting. Microsoft's documentation is a bit obscure about this, so perhaps an example can show it more effectively.

This screen shot shows several instances of the DOCPROPERTY Category field code:
User generated image
The next screen shot shows the results of the same field codes:
User generated image
As you can see, the MERGEFORMAT switch set the result as bold when the full field code was bold, but not when the 1st character was set to bold and to red to match the formatting in effect for the line that contained the field code. It also ignored the formatting of the 1st character.

Without the MERGEFORMAT switch, you can see the same result when the full field code was set in bold.

However, you have more control when you manage the formatting by applying it to the 1st character of the field code: the 2nd result is bold; the 3rd result is bold and red.

The 4th result shows the real advantage of this method: it does not include the underlining because underlining was not included in the formatting for the 1st character — even though the rest of the field code had the underline attribute applied.

For a template, I would use this 1st character formatting method to be able to more specifically control the format of the field code results.

Although the options are described in this Microsoft support page, the MERGEFORMAT explanation is a bit unclear in my opinion.
Avatar of kasperEH
Flag of Denmark image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Using an older version may have solved it in this case for you, but the reason it worked is due to the rules I described. The template is exactly like a document: when a field is refreshed when the MERGEFORMAT switch is included, it uses the formatting that was in effect when the field was last refreshed (in most cases, the format of the paragraph, cell or text that contains the field code). When a new document is created from a template, the formatting from the template is retained and in effect.

This has been a very-poorly documented part of field codes for many years, so I do understand your confusion.

As with many aspects of Word, the key for reliable and predictable formatting is to remove any potential ambiguity — and as my example demonstrated, MERGEFORMAT is risky because it isn't always clear what formatting will be applied to a field code until after it is updated. This can be particularly vexing when someone inherits a project, because if they change some formatting in a cell, it won't necessarily be reflected in the field code results. This is why I recommend the more explicit method: it will be visible to anyone modifying formatting when they toggle the field code views.