>Hi
>
>I have reports that print on a dot matrix printer. The dot matrix printer can be in draft or NLQ (near letter quality). Whenever my reports print, the printer setting is changed to NLQ, which is slower. Is there anyway to tell the report to print in draft? I saw an API called PRTINFO which can give me the current quality setting of the printer when I pass a parameter 8. But I dont know if I can set it.
>
If you're not sending any fonts and are relying entirely on the native printer settings, you can use the Generic/Text Only Windows printer driver when installing the printer under Windows. This will send ASCII characters straight to the printer without adding any control codes to your output. The output will respect the current printer settings, however, this also means you can't use fonts or switch print modes conveniently using the report writer.
If you only create output to go to that model of printer, you can make sure that the printer driver is installed on the development machine, and then limit yourself to selecting fonts native to the printer (when you're selecting fonts for your report, only select fonts that have a little printer icon next to them on their left in the Format/Fonts dialog, not ones with no icon on their (these are native Windows fonts that must be translated to graphic output in most cases) or the TrueType icon next to them (these are scaleable graphics fonts that are sent as graphics to most dot matrix printers). Native fonts will print almost as quickly as unformatted text, and in most cases, distinct fonts for draft and NLQ modes are available in a variety of (fixed) sizes.
If you do this, make sure to set your report's default font to one of the native printer fonts before starting to design the report. if the report is already designed, you'llhave to go back and change all the fonts to native fonts to get the performance of the native fonts, and may have to readjust the report layout slightly to allow for differences between the native fonts and the fonts you originally used int he report.
If you're willing to accept the limits of the printer, and are willing to commit to always outputting to that printer or an equivalent model printer, this will give you best performance from the printer while taking advantage of any built-in fonts and proportional spacing capabilities on your printer. If you want to print anything other than these fonts, you'll be forced to send the characters as graphic images, which will be slower, especially the TrueType fonts. If you use native printer fonts, but then change the type of printer, the original native printer fonts may not be available, which will force Windows to use a graphical font, and will also force Windows to substitute a font that is supported by the Windows GDI drivers using the Windows font substitution tables, which may not be what you want.
In general, if you don't have control over the exact model of printer in use on all machines that will run the report, this is not a good option, especially for dot matrix printers, which have a limited selection of fonts and font sizes available. This approach runs contrary to most general-purpose Windows programming practices, because it makes your output hardware dependent - you can't substitute a different piece of hardware and get the same results.
