GDI works behind the scenes, providing a standard way to communicate to a graphics device via the Windows Application Programmers Interface (API).
It acts as the "glue" between the Windows API and the printer driver.
Programmers usually do not need to concern themselves with what type of printer has been selected by the user, because all printer drivers are required to support the minimum subset of operations in order to function properly.
The main thing that differs between printer drivers is the resulting output of the driver.
The primary element of GDI is the device context, or DC.
A DC provides a virtual surface to the application programmer that has a 2 dimensional coordinate system.
A DC can represent a printer, the screen, or a bitmap. Often, the same parts of the application that render elements of a programs visual display to the screen are used to render those elements to the printer, because they both are represented by a DC.
A device context includes a data structure called a DEVMODE. This structure describes things common among all graphics devices such as resolution and orientation, as well as an extra device dependant portion attached to the end.
This extra portion at the end is generally undocumented, but contains state information for additional features that are selected during the Page Setup and Print Dialogs.
The DEVMODE is passed from stage to stage with the print file throughout the printing process all the way to the Port Monitor.
There is nothing automatic about rendering elements to a DC. The application programmer must position the "cursor" in order to select where elements are drawn, and calculate if there is enough space to render that element in the position selected.
The application programmer calculates things such as word wrap and positioning of content.
Sometimes, problems are blamed on the printer driver or the printer itself instead of the application because calculations are performed erroneously, unsupported fonts or features are used, or rounding errors come into play.