Thanks Ed for your kind explanation. Without you this place was so boring...
But if you sacrifice your precious time and look at VFP HELP you will see such sentence "The number of columns and rows on each page in the ASCII text file is determined by the contents of the _ASCIICOLS and _ASCIIROWS system variables."
In such way works this command in VFP6, now in VFP7 it DOES NOT (this for me is the bug). In VFP6 REPORT FORM ... TO FILE ASCII command in conjuction with properly set _ASCIICOLS and _ASCIIROWS produces ASCII file with layout VERY CLOSE to graphic layout. I was really suprised that my customers (sales points with dot matrix printers) accepted such quick and dirty solution. I've planned to make character mode reports by using FoxPro DOS but using REPORT FORM ... TO FILE ASCII I did not have to do it. In such way I can drink beer+vodka and watch stupid TV soap opera (probably this is the reason why my brain is so demaged) instead of working with FoxPro DOS report designer.
Next sentence is in your style.
You do not understand that designig one report takes less time than designing two reports (one graphic mode + one text mode).
Ed your explanation are often great (honestly), but your style...




>>I'm sure it is a BUG. ASCII file layout should be as similar to graphic report layout as possible. After removing blank lines my page footer prints at the middle of the report page (dot matrix printer character type printout).
>
>Not true; your printer selection is a bug!
>
>You've selected a printer behavior under Windows by associating a printer driver with the Windows printer. If you do not want to associate GDI behaviors with a printer, you need to select the Generic/Text Only printer driver for the target printer.
>
>The problewm here is that you do not understand what a Windows printer is. Windows printers are inherently GDI (Graphic Device Interface) targets. The way Windows works is to virtualize the graphic device, so that all roughly equivalent devices have equivalent graphical renditions. Windows treats the printer as a graphical device unless you tell it otherwise by selecting the Generic/Text Only driver.
>
>VFP'sa ASCII representation is a bad attempt to convert an inherently graphical output format that works by precise pen positioning and equivalence of render for a row/column model of display. Windows isn't good at this - it has no information on page size, character width and height, and all the other things that go into creating equivalent output on similar devices.
>
>If you want to produce row/column oriented output, the VFP Report Writer is the wrong tool to use; unless you design at all times with a monospaced font at a size that exactly equates to the font supported by the target device, you'll find it incredibly difficult to properly align output using the DOS device model of behavior.
>
>You're trying to cut down a giant tree with a tool that's closer to a surgeon's scalpel than a chainsaw.