It is difficult to answer your question because it is not trivial to list the difference in the Unidrv code path depending on the PrinterType. The decision on whether true type fonts are printed as text does depend to a certain extent on the PrinterType attribute. But it also depends on other factors. So your last question cannot be answered definitively and the only answer is that it really depends on your particular scenario

- Ashwi

Microsoft Printing, Imaging and Fax Tea
This posting is provided "AS IS" with no warranties, and confers no rights

Ashwin,

This question is one of the first questions any developer will ask when faced with
developing
a Unidrv-based driver. Unfortunately, there is *no* documentation whatsoever on this
attribute, which has fundamental implications on how the driver behaves. I've been doing
drivers based on these models for years, and I still have questions about them.

You really should provide some kind of overview for new developers get pointed in the
right
direction, so they aren't left to experiment and debug each of the different types. I'm
sure most
of us understand the predicament of documenting something so complicated, so a high-level,
conceptual description would be sufficient. At least better than "it depends" or "it's
too
complicated to describe"

Eric

"Ashwin [MS]" <ashwinn@online.microsoft.com> wrote in message
newsE1541C0-8BC9-43F0-AA63-AE689AA676DE@microsoft.com...
depends". In the typical case, just setting the PrinterType to TTY should suffice for a
text-only printer. But it can depend on a lot of other factors and really comes down to
your particular GPD or driver. As for the sample implementing rendering and UI plugins,
that is because the sample implements further customization through methods like
IPrintOemUni::TTYGetInfo and IPrintOemUni::OutputCharStr.