JDBP>> I've seen this statement before, but I have difficulty squaring it
 JDBP>> with many years of people using ordinary dot-matrix printers with
 JDBP>> DOS to produce graphical output with no difficulty at all.  DOS
 JDBP>> programs have been doing all of the rasterisation for relatively
 JDBP>> unintelligent printers for many years.
 JDBP>>
 JDBP>> I suspect that "Windows printer" refers more to the lack of
 JDBP>> support, in terms of shipped (or indeed, developed) drivers
 JDBP>> and font files, for DOS applications.  In other words: no
 JDBP>> more little floppies with subdirectories named \ACAD,
 JDBP>> \PARADOX, \123, and suchlike.
 GW> Most Windows GDI printers have absolutely _no_ internal smarts, some
 GW> have just enough to support basic text printing under DOS.
The dot-matrix printers that I was referring to above didn't have much in the 
way of intelligence, either.  All graphics output was essentially a sequence 
of bytes, controlling the states of 8 matrix pins.  Nevertheless, such 
printers were usable from those DOS programs that performed the rasterisation 
themselves, performing all of the graphics calculations in memory to 
determine what bit pattern to send to the printer.  
If the term "Windows printer" means nothing more than that printer technology 
has regressed to the level of early 1980s dot-matrix printers once again, 
then there's no cause for all of the worrying that people are doing about 
this.  DOS applications probably _could_ use such printers. After all, that's 
the sort of printer interface that they _had_ to use some years ago.  I 
suspect that the only problem would be lack of will when it comes to 
developing all of the printer drivers that would be necessary -- especially 
since there is no standardisation across DOS applications for such things.
As I said above, driver support is the crux of the matter, not how "smart" 
the printer is.  "Dumb" printers are not a problem for DOS applications, 
because have been dealing with dumb printers for _many_ years.  It is whether 
the drivers will be written or not that is the key.  More likely than not, 
for marketing reasons a printer marked with a "Windows printer" badge will 
_not_ ship with the little floppy disc containing reams of printer drivers 
for various DOS applications that we have become used to in recent years.
As for DOS+Windows and OS/2 Presentation Manager driver support, I suspect 
that the printer manufacturers will be more willing to spend development 
effort on those two for a "Windows printer", because DOS+Windows and OS/2 PM 
are perceived to be "modern" and "graphical", in contrast to DOS.  There is 
nothing inherently hard about writing a Windows or PM printer driver that 
performs all rasterisation in the host's main memory and sends the resultant 
bit image to the printer.  In fact, it is probably _easier_ to write such a 
driver that to write one for (say) PostScript, considering that in-memory 
rasterisation was, originally, what most Windows and PM printer drivers had 
to do, and that the way that Windows and PM converse with printer drivers was 
thus as a result geared around that design.
 ¯ JdeBP ®
--- FleetStreet 1.19 NR
---------------