>Thank you very much for responding. I tried using roman,10 (the front panel has a typeface roman), but the printer acted very funny (shooting out pages etc.). There is no other font in the font list that matches the fonts on the front panel.
You can't just pick 'Roman 10'; you have to have the Epson printer selected as the default printer, and use
only native Epson fonts (fonts that appear with a little printer symbol appearing to the left of the font in the Fonts dialog, not the ones with no symbol (these are the native Windows graphical fonts, which are not continuously resizable, and are never resident in the printer) or a stylistic 'TT' symbol to the left (these are TrueType fonts, which are sizable graphical fonts; some printers, notably PostScript and some of the HP compatible printers, can download these to the printer as a temporary font definition, but are always rendered graphically on a dot matrix printer.)
What appears on the front panel has nothing to do with this - Windows has to know to use a resident font with the printer. If you pick a native font resident on a different printer, Windows will translate that to a nearest-equivalent Windows font and render it graphically, often with spectacularly poor results because of the non-equivalence of the font. Again, to use native fonts, the printer must be selected and active during the Report Design phase, and you must use
only native fonts, or Windows will render them graphically while printing. You must use
exactly the printer driver that will be in use on the target printer - it isn't enough to have JRandomEpson driver in place, you need the one for the
specific model in use, since different models have different native fonts, and use different print codes to select and control them.
Sorry, but in order use the native print fonts, you must make your report hardware-specific and select only the native fonts for all output, or live with the fact that the Windows GDI will have to interpret things and render them graphically. Different printers use different print codes and have different native fonts - even if two printers in a manufacturer's product line have the (supposedly) same native fonts, the appearance of the font on the printout may be different from model to model using the native font, since the native font may be built internally with different resolutions, character height, width, and stylistic variants. Life sucks, but this is the reality of printing in the Windows environment - in order to create consistency in output appearance in a hardware-indepent fashion, Windows is forced to use graphical rendition managed through the GDI portion of Windows, and on a dot matrix printer, that translates to
s l o w printing.
The class I posted writes directly into a printer's spool queues, completely bypassing the GDI and standard Windows paper handling behaviors, but it doesn't work with the native VFP Windows printout creation commands such as the report writer. It makes you completely responsible for handling the output, which must be done in linear fashion, in a hardware-dependent and possibly hardware specific fashion in creating output using the class' DocWrite() method. If you want to use the native VFP utilities to create your output like the REPORT command, you're out of luck. I don't know about the other guys' offerings as far as assuring hardware independence and compatibility with the native VFP output tools, but my understanding of how
Windows works in rendering text in the graphical device mode precludes it from allowing you to reference any non-native font and outputting it as anything but graphics.
It ain't a VFP thing, it's a Windows thing.
