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.
--
Peter Jamieson
http://tips.pjmsn.me.uk
"Mathijs" wrote in message
news
In our HRM application were 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 were working with
bar codes it doesnt seems to work correct anymore.
This is the way were 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 weve 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 wouldnt exist.
Also when were using the same method with Word 2000 the problem doesnt
appear.
My question is therefo 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 isnt open for me Im not able to
influence the code used for the mailmerge so maybe there is some registry
which will fix this problem?