Avatar of kasperEH
Flag 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.
Microsoft Word

Avatar of undefined
Last Comment
Eric Fletcher

8/22/2022 - Mon


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.

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.

If it can be edited to remove any confidential test, I suggest that you attach the document here.
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck

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.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.

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

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:
Example lines showing the field code view (Alt-F9 toggle)
The next screen shot shows the results of the same field codes:
Example lines showing the results of the field codes being controlled by various formatting options
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.
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Eric Fletcher

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.