Undesired Japanese characters in mailmerge

[Mathijs]

In our HRM application we’re working with a wizard to create. (More than 100
different letters a day)

The HRM application (MS Access based) exports the output of a query
towards a temporary text file.
The HRM application opens the concerning letter in MS Word 2003 and uses the
text file as the source for the mailmerge.

For normal text this always worked correct however now we’re working with
bar codes it doesn’t seems to work correct anymore.
This is the way we’re generating the barcodes
In the MS Access query we generate the desired text string (surrounded with
some ASCII characters in the range over 128, this to tell the Font how to
generate a correct barcode).
After we’ve started the mailmerge we simply select the correct Font for the
text string in MS Word and a barcode will be generated.

Now the problem is that MS Word automatically considers this text file as
Japanese characters and therefore it damages the barcode.
If MS Word would use the Windows standard codetable (western ISO) instead of
the japanese code table this problem wouldn’t exist.
Also when we’re using the same method with Word 2000 the problem doesn’t
appear.

My question is therefore: Is there a possibility to tell MS Word 2003 always
to use the Windows standard instead of Word trying to think for us and making
the wrong decisions?
Because the HRM application source isn’t open for me I’m not able to
influence the code used for the mailmerge so maybe there is some registry
which will fix this problem?

 

[Peter Jamieson]

If it is the HRM application that opens the data source (the text file) then
I think it would be difficult for anyone except the supplier of the HRM
system to modify this.

However, assuming that you define the Word documents in your system, it is
possible that /you/ define how Word connects to the mail merge data source.
In that case it may be possible to do something.