Albert,

what I meant to say is that there are differences between pdf's generated by Adobe Acrobat Writer and Distiller. Do you know what application created the pdf. The replacement of these characters does not happen when using Distiller, it will happen with PDFwriter.

Regards,

Ron

>Hi Ron,
>
>I do not use either of these - the users are firing up Acrobat and then sometimes they need to make small changes so we actually fire up the full version of Acrobat - Acrobat.exe. I do this via the run command e.g.
>
>RUN /N1 &lcProgFilePath &lcDataFile
>
>where lcProgFilePath is looked up on their hard drive dynamically to determine which version of Acrobat they have and lcDataFile is the .xfdf file that contains the xml string that is then "merged" with the pdf layout form.
>
>Thanks,
>
>Albert Gostick
>
>
>>What do you use to generate the pdf. Adobe Writer or Distiller. Writer has problems with these characters, Distiller does not.
>>
>>Regards,
>>
>>Ron
>>
>>>Hi Everyone,
>>>
>>>Someone helped out with this 6 months ago when my VFP app was sending accented characters to a text file that Adobe was then opening and importing. At that time, the character was the accented e (é). Someone pointed me to this code which worked:
>>>
>>>

>>>
>>>STORE STRCONV(lcOldChar,1) TO lcNewChar
>>>STORE STRCONV(lcNewChar,9) TO lcNewChar
>>>
>>>

>>>
>>>which essentially I used to convert the VFP data to double-byte chars and then to UTF-8 chars (which is what the xml/text file is in that Adobe uses).
>>>
>>>This worked for quite a while until some user entered an accented z (ž - made with Alt+0158) and somehow the above process translates it to a bunch of chars:
>>>
>>>ž
>>>
>>>Which Adobe chokes on and does not translate back to the ž.
>>>
>>>Anyone have any ideas of how to get around this?
>>>
>>>Thanks,
>>>
>>>Albert Gostick