I have some experience working with the Windows printing subsystem in the past. I’ll give this a shot…
There are two interfaces that are involved: The interface between the application and Windows, and the interface between Windows and the printer. The two interfaces are often completely different. The printer driver provided by the vendor acts as the middle-man and helps the system convert the print data generated by the applications using the app/Windows interface to the Windows/printer interface.
Printer vendors are free to choose whatever they like to be their Windows/printer interface. As long as they supply an appropriate printer driver package, things will all work out correctly. In reality, a few industry standards, such as PS and PCL, have evolved over the years, and are supported by many middle to high end printers. However, it does require a fair amount of efforts to properly interpret these languages on the printer. Therefore, lower end printers tend to use proprietary protocols that are more easily digestible.
On the application/Windows side, this is traditionally done using GDI. This is the same interface that applications normally use to draw on the screen. Therefore, from the application’s perspective, drawing on the screen and printing on a page are somewhat similar, at least in principle. There are some differences in reality, of course, but that gets complicated and I won’t go into the details here.
GDI was originally developed in the 80s. Given the advances in technology, it is starting to show its age. As a result, a new XPS printing path was introduced in Windows Vista. This technology is based on the XML Paper Specification, which has some similarities with the PS and PDF standards. Compatibility modules are also provided by the operating system so that both GDI and XPS applications and printer drivers can interoperate with each other.