>Does anybody know a way to print fast reports on a dot matrix priter.
>I've tried a lot of soluction like:
>
>1- Sending output to a ascii file.
> problem: - What you see on your report writer it's not what you
> see on you printer. It is a mess.
> - You can't use special character like ñéá, that are
> useful in spanish world.
>
The use of text file output is only acceptable if the characters you need are native to the printer. You have to give up the concept of preview in most cases, since the character set mappings in the printer probably don't correspond to the character set in your screen fonts.
>3- Using others fonts like foxfont,ms san serif, etc. This print so
> slow that could not be taken into consideration.
>
>Coud somebody help me with this? Is there a true type font that i can use?
The problem is that, like the other fonts you mention, TrueType fonts are treated as graphical representations of the character; they're sent bit by bit as a graphic to a dot matrix printer in almost all cases (a very small number of dot matrix printers, none of them in the inexpensive or commonly encountered categories, have enough memory and the necessary Windows drivers to download a graphical font to themselves, and none that I'm aware of have the necessary intelligence to deal with TrueType fonts, which are scalable.)
The overhead for TrueType fonts can only be reduced by sending the character sets(s) to the printer for storage and intepretation by the printer; this would require a PostScript (or equivalent intelligent printer language) capable printer. I've seen PostScript-based DMPs in the past, but they aren't cheap or readily available. Unless you're forced to use tractor-fed multipart forms, you're looking at a cost perhaps 5-10x the cost of a low-end laser that would handle graphical output much more easily and far more quickly.
If you want to not send characters as graphical representations, you have to bypass Windows' printer-specific driver (for example, by using the Generic/Text-only printer driver for the printer in Windows) and sending control codes yourself in the outputr stream (several mechanisms for doing this can be used) and giving up on screen preview, or using different report mechanisms when outputting to screen and printer, so that the isse of character set mappings and control codes don't get in the way.