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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


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.
kasperEHAuthor Commented:
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.
Fundamentals of JavaScript

Learn the fundamentals of the popular programming language JavaScript so that you can explore the realm of web development.

Otherwise,  following on from AmazingValor's suggestion, try selecting all the text and toggling the Bold setting (leaving it Off)
kasperEHAuthor Commented:
Here is a version of the template, where I have removed most of the text, but the problem is still there.
kasperEHAuthor Commented:
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
kasperEHAuthor Commented:
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 FletcherCommented:
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.
kasperEHAuthor Commented:
Thank you for your detailed and informative text, Eric Fletcher. It didn't quite solve my problem. I tried to remove MERGEFORMAT and change the formatting of the first character, but the problem stayed the same.
I found a solution by restoring an old backup of the template without the error messages, before I had run a refresh of all fields in the template. Then I carefully added all the important changes since then and that did the trick. So I think the lesson is to only run refresh of fields/variables when a document is open, not a template.
Thanks all for your comments and input.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Eric FletcherCommented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Word

From novice to tech pro — start learning today.