>Dragan,
>
>Seems this approach does not work for MailMerge anyway, because datasource does not include unicode or UTF8, but txt only.

UTF8 is text. Since this is mailmerge, why not use .dbf as datasource? I've done that, in English though, and I really don't remember whether I was using native VFP or Fox2x tables; still, Word2000 was accepting .dbf as mailmerge source. It's just a matter of whether the driver it uses while reading them will pay attention to the codepage or not. Anyway, it was worth a try. I just tried it with a codepage 1250 table, and set the language in my merge document to Serbian (Latin) - the language specific characters still don't come across as converted. I also tried converting a field to DBCS, Unicode, and UTF-8, but Word doesn't recognize them as such and behaves as if they contain garbage, i.e. displays them as they are.

You could only write a word macro to transform the merged document, which would need some tweaking (i.e. you'd want to control the merged document creation process and to run the macro from the main document on the merged one). I remember I had to write a few such macros while there was a codepage chaos back home - they don't look nice, and depending on the number of changes needed and the size of the document, they may look really ugly. If you could just get Word to mailmerge a field passed as a parameter to a conversion function, that'd be great - that way you could run the conversion on-the-fly and on the few merged fields only, not on the whole merged text.

Word is actually lacking many string functions VFP has, and I remember that it was far easier to scan a Word document word by word using automation and do the conversions within Fox, because Fox can code circles around VBA when it comes to string manipulation. Funny, I thought Word was a text processing tool.