>>I would say it is by design -- using a rendering model where commands are immediately interpreted by the printer, the ability to overprint white on top of black would require the *removal* of ink from the paper. Or if we've got opaque white ink... The only way around this would to require a model where the commands are sent to a render buffer before committing to actual ink.
> This is what we got already with VFP report engine. There is of course buffered rendering.
Question was not about physical implementation, but more logical.
The problem is that what's useful for one type of usage might not be logical for another. For some purposes, operating as if you've got opaque ink make sense (allowing one to "erase" areas with "white"). For other purposes, the ability to "blend" colours by overprinting would be useful. True, using a render buffer would allow either operation to work, it would probably require a fair amount of memory (either on the printer or on the PC itself) to implement -- especially when you take into account that printers are usually higher-resolution than video display in terms of DPI (monitors are typically around 96DPI while a typical printer *starts* at 300dpi). I would hazard to guess that the implemention used in FoxPro for print rendering was the one that required less memory (i.e. let the printer handle the details).