You are absolutely correct Ed, the prospect is reluctant to use appropriate equipment and the Sales department is reluctant to tell the prospect that they must spend an additional $600 for a compliant POS printing device! It is a competitive world, and we must go hand to hand with our competitors every day. We must have a better solution at a like price or a like solution at a better price. We have 900 POS systems installed and we continue to grow every day in a Global market. Unfortunatly we encounter existing systems where the proprietor has an investment in existing hardware which he does not want to loose. We must bend so as not to break. However it usually is me who is the bender and it is the software that gets bent.

I think I will explore your suggestion regarding the FP DOS style printer driver file. There may yet be a way to preserve a little sizzle and allow the customer to save a few hundred as well.




>>Thanks Ed for your fine explanation of this sometimes confusing windows printing environment. We develop software for the Retail Book business and need to support many different POS printers. It is a daunting task in VFP to produce attactive output ( product sizzle ) and yet keep development costs minimal. We have found as you stated that making a report device dependent will work unfortunatly we do not have the luxury of developing 30 different reports for 30 different printers. I am still working on a table based solution to this dilema. If you have any suggestions I would be thrilled to entertain any reasonable options.
>>
>
>I feel your pain - I also work in the publishing industry, supporting a publishers' order processing, royalty and order fulfillment system. The price tag on the product is high enough so that when I specify the supported range of report printers and their relative performances, I have little trouble getting the client to purchase adequately high-end PCL5 compatible or PostScript printers for invoice creation and report preparation - if they need to print several hundred invoices in an hour when releasing backorders, it's not cost-prohibitive to spec something like a pair of HP 5si printers to service a shared spool queue. It's a business decision, and since I'm not addressing a bulk retail, mom-and-pop business, the fact that I spec out something other than the $89 ink jet printer that came with the Compaq Presario isn't an issue - in a world where the typical shipping station has a scale, barcode gun and form-oriented thermal label printer, checkin and packing stations a barcode gun
>and a ZPL-compatible thermal printer, and several shipping lines in each warehouse, explaining that a low-end printer isn't going to cut it is not a problem; these guys are buying either strapping machines or in some cases the big automatic boxing/taping machines that use chemical foam fill to protect the shipped content (typically in the $15,000-$30,000 range). A couple of (or ten) grand in printers is a small part of the overall cost of fully automating their operation to handle $20M in gross sales.
>
>Actually, the old FPDOS approach of using the old Printer Driver database isn't a bad one; I tell my customers who feel compelled to use DMPs/inkjets to have someone create a Generic/Text Only printer in Windows and then customize each station's driver to handle the limited range of supported printout enhancements and give up sizzle for speed; the Generic/Text Only driver can be configured for a few modes like compressed, italics and boldfacing inside the Windows Printer Driver setup (an issue outside of VFP). Then they just point the output of the stations limited by their output device to the appropriate Windows Printer name they've installed and customized. This usually means storing configuration detail on a station by station rather than a user or app-wide basis; the creation and reference of Registry Keys under the registry hive HKEY_CURRENT_CONFIG is a relatively simple mechanism for storing station-dependent configuration detail.
>
>In most cases, since barcoded output is nearly always required for part of the output process, and DMP/Inkjet printers don't reliably produce barcode output that meets the compliance requirements for shipping carrier 1D and 2D barcoding with a range of environmental conditions and print media (differences in humidity, absorbance and reflectivity of the paper, and ribbon or ink cartridge condition radically affects the reliability of barcoded output on these low-end printers, and in most cases, you're looking for 5 9s readability of the output to make barcoding considerably improve productivity - 90% reliable output means that one barcode in 10 is unreadable, which affects the work flow) I can get them to at least spring for a low-end laser for their work, which is going to be faster than a DMP in native mode with limited native sizzle ability, even with graphical rendition of the output on the laser in most cases.
>
>All I can recommend is a better grade of customer...or at least one who recognizes that their business' interface to the outside world, and reporting to management, depends greatly on the appearance of the printed document, which is directly linked to the quality of the print device.
>
>When you find a way of weeding out the hosers, PLEASE let me know the secret!
>
>>Thanks
>>
>>
>>>>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.