Home |
Search |
Today's Posts |
#1
![]()
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
![]()
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? |
#2
![]()
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
![]()
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? |
Reply |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Automating Mailmerge using CSV results in squares / Japanese characters | Mailmerge | |||
Help merging japanese characters | Mailmerge | |||
Entering Japanese 'furigana' (phonetic characters) | Microsoft Word Help | |||
Word 2000 - japanese IME doesn't enter characters | Microsoft Word Help | |||
How do I use Japanese characters in Ms Word 2000? | Microsoft Word Help |