how does Windows app to printer device interface work?

I know about existence of . I also know that certain apps, e.g. those of Microsoft Office family, have historically made some effort to make their documents inaccessible to tools not sold by their own company. That makes me wonder - when Microsoft Word prints a document, what PDML does it generate to send to the printer? Can it generate multiple ones, let’s say because some printers don’t support some of them?

How do printer manufacturers decide which PDML to support anyway?

If I were to write a new app, say CodeGrey Office that authors documents in proprietary .cgo format, how would I go about dealing with the printing issue? Outputting to which format would I need to support to allow for convenient printing?

Are the above questions even meaningful or do they reflect a fundamental misunderstanding of how the app-to-printer process works in the first place?

PCL (hp) has been standard since the 80’s for laser printers.

Postscript is the other common one.

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.

Waffel Decider,

suppose I want to do some “machine vision” / OCR type of stuff on the printed output of a program or possibly also on its output to screen. Instead of starting from all the way down at the bitmap level (sort of what we would get from PrintScreen or from running a printout through a scanner) can I somehow register my app as recipient of the GDI output and then reasonably easily parse it? At least, parse it to the point of recognizing the location of strings and some of the more prominent lines and rectangles drawn on the page, i.e. about the level of geometric sophistication we get from vector graphics editor in PowerPoint?

It sounds like this can be done either with a virtual printer driver or a print processor, depending on what you’re doing and how you want to plug into the system. I’ve worked on a product for my former employer (now defunct) that does something similar. It is a product that helps the user extract and layout all the text in a print job. It is a printer driver package, and once it is installed, it looks just like any other printers to the application and to the user. The plain text output can then either be redirected into a file, or be sent to a serial/parallel/USB/etc printer port to a physical printer that understands plain text input.

This type of software can get pretty complex and may require a non-trivial amount of efforts, so you may want to be prepared for that…

I htink you want to hook the GDI input, not output. In other words, you want to be notified when the user program calls Windows’ GDI interface and passes a data block saying “at page-relative coords 300,400, write the characters ‘code_grey’ in Albertus Bold 12 point”.

If you were given that data block, you could readily determine what the program was doing.

Naturally, for any page content which is less textual / more graphical, you’re still stuck trying to intuit semantics from what amounts to graphic syntax. But you are one level farther up the conceptual hierarchy from trying to convert a bitmap into logical features.

Is it possible to hook the GDI interfaces? I don’t recall.
Meta-comment: You’ve asked 3 or 4 questions here in close succession which leave me wondering what your actual goal is. They each appear to be tackling things inside out & backwards based on an apparently partial understanding of how Windows & Word work.

Perhaps if you described what your actual use case / user story is we might be able to get you pointed in a more successful direction.
ETA: As **Waffle **says, a virtual printer driver is the supported way to “hook” the printer interface. Some dimly half-remembered factoid from 15 years ago is suggesting to me there are GDI virtual screen drivers as well. But I recall that stuff gets ugly deep real quick.

A mirror display driver is the equivalent of a virtual screen driver. I’ve dealt with that on another project too. And yes, it gets UGLY real quick. It also doesn’t integrate that well with the new display driver model introduced in Vista.

I can’t answer about *CodeGrey Office.

*Typically your software tools offer a method for printing. In C# I open a print document and I draw to it like I would the screen. The magic occurs at the OS level which prints to the selected print driver - the driver does the work of printing to the device.

So for instance, if you have a PDF print driver installed, when you print to that driver, the driver will output it to PDF format.

In C# I can choose to print to the default printer, or open a print dialog and let the user choose.

The purpose of print drivers was/is to take the onus of knowing about the individual printer formats away from the developer.


the central question on my mind is “what’'s the simplest way to get coordinates of text and prominent lines/rectangles in a printed document”. To use an analogy, a small subset of XAML (containing labels, textboxes and maybe pictureboxes) could serve as a simple, very human readable markup language to describe a printed page with a bunch of formatted text. So, wouldn’t it be nice if there were a simple way for me to use “virtual printer driver” or something along those lines to obtain a XAML (or similarly simple) description of the printed page?

The other questions I am asking reflect, yes, a life-long quest for understanding and battle against ignorance :-). Now on to splitting rocks, being merry and watching Simpsons reruns :slight_smile: