As an aside, Shihchau:

VFP's report to ASCII feature is highly dependant on the current printer's driver. You will get vastly different results with different printer drivers. If you don't have very many reports to worry about, you should experiment with different printer drivers when printing to ASCII.

As another aside, Adobe allows _you_ to distribute their software with no license fee or anything, if you decide to go with pdf. Our customers complained a bit when we told them they had to go to Adobe's site, fill out all the BS marketing forms and then download the reader, but they were happy when we allowed to download it directly from our site.


>VFP6 uses Report to ASCII to generate HTML. It has the same truncation problem.
>
>
>>Well, you can still use the report to ASCII, but you'll probably have to tweak it and you may end up needing one for ASCII and another for printing. You could also skip the report writer all together and use VFP's TEXTMERGE feature to send text directly to a file. If you need formatting, you could create it with HTML pretty easily. I trust your customer would consider HTML standard enough.
>>
>>>Looks like I am in deep shit. My customer doesn't like the idea of asking his business associates to download 3rd party reader to read email.
>>>
>>>MS should do a better job than this.
>>>
>>>
>>>>In my experience reporting to ASCII doesn't work very well. You may want to move PDF up your list options a bit.
>>>>
>>>>>When I print report to a ASCII file, some of my data fields are truncated. I guess my alternative is to set 'stretch when overflow'. But it is not a good idea to keep a 2nd copy of report format just for this. PDF is my very... last resort.
>>>>>
>>>>>Is this a MS bug? Anyone knows a way to overcome this?