>Thanks for your answer but my customer asked HP what they taught about it and here is what they had to say.
>
>HP's answer
>"Thank you for contacting Hewlett-Packard's Customer Care Technical Center.
>
>The file you indicated is the PCL6 driver file. In the case of the Particular
>software you have the issue with, it might be best to use the PCL 5 or
>PostScript driver. Some software requires the use of an older driver, such as
>the LaserJet 4, 4V or 4SI drivers to print correctly."
>
>
>the LaserJet 4, 4V or 4SI drivers to print correctly>
>
>Would you think this is the case with VFP5 ? or Win95 ?
It's a known issue with VFP5 and the HP 40xx PCL6 driver - HP does not reset the state of the FPU before returning to VFP, which may hang VFP. Using one of the MS operating system distributed drivers for a compatible printer will prevent this problem - MS's drivers don't have this problem. The MS drivers are not as 'feature laden' as HP's drivers, andmay not take advantage of HP's model-specific enhancements, but do handle things like tray selection, paper sizing and paper orientation in a standard fashion, and looks almost identical with comparable resolution modes set for the drivers.
Using a PostScript driver lets the printer use it's internal engine where it can, at a slight performance cost. PostScript can be used for emailing documents in a similar fashion to PDF files using the FSF GhostScript/GhostView tools; it requires a bit more work to set up, and you end up paying for the commercial use of viewer tools rather than the generator tools like PDFs, but if your printers support PostScript, it means that output destined for both printer and viewer will always use the same driver, making printer selection less of a chore, and often allowing you to pool otherwise dissimilar printers in a network environment. Macs and Linux like PostScript. In Windows, it does require extra planning to work with printers without internal PostScript support; GhostScript offers a translation layer that translates PostScript into a format handled by the Windows GDI, so that other Windows printers can process PostScript output. You can get more information on commercial use of GhostScript at http://www.artifex.com - I personally use Alladin GhostScript and GhostView, available from http://www.ghostscript.com as well as most FSF/GNU distribution sites (gazillions of large universities, places like www.cdrom.com, and the big download sites will have one or more GhostScript offerings.)
>
>When you issue REPORT FORM Filename1 NOCONSOLE NOWAIT TO PRINTER , am I correct in assuming that VFP formats the report then sends the output stream to the printer queue which is handled by Win95 ? So what is the issue with VFP and printer drivers ?
>
VFP sends the report to the Windows GDI, which routes it to the print queue via the driver. The issue is the state that the driver leaves the CPU in (specifically, the FPU/MMX registers are not reset to a determinate and stable state, and graphic output does use the FPU, and in some cases the MMX instruction sets to generate the print stream) when the driver finishes it's job. If the FPU is left in an indeterminant state and VFP tries to use it, a floating point error occurs, smashing up the VFP's process and shutting it down in an ungraceful and rude fashion. There is a workaround; you can declare the C library DLL entrypoint _fpreset() and call it after every time that VFP accesses the printer (realize that many things like print previewing will call the printer driver, even though you don't print anything). You can declare the entrypoint by:DECLARE _fpreset IN MSVCRT
and call it by:=_fpreset()
after every call to the printer driver. VFP6 SP4 finally added code to deal with this annoying problem; it affects all versions of VFP up to and including VFP6 SP3, and also affected FPW as I recall, which required the use of FOXTOOLS and RegFn()/CallFn() to access the API function.
It affects most HP-issued printer drivers at some point in their lives, as well as a few other drivers on an irregular basis. It's really not VFP's fault; it expected the driver to behave as documented, and the OS actually catches the error and terminates VFP as a result.
--another (dis)satisifed HP victim
