Download Graphics Device Interface-Windows Programming-Lecture Notes and more Study notes Windows Programming in PDF only on Docsity!
13.1 GDI (Graphics Device Interface)
In previous lectures we have got some understanding about GDI. In this lecture, we will take a detail look on Graphics Device Interface and its Device independency.
The graphical component of the Microsoft® Windows™ graphical environment is the graphics device interface (GDI). It communicates between the application and the device driver, which performs the hardware-specific functions that generate output. By acting as a buffer between applications and output devices, GDI presents a device-independent view of the world for the application while interacting in a device-dependent format with the device.
In the GDI environment there are two working spaces—the logical and the physical. Logical space is inhabited by applications; it is the "ideal" world in which all colors are available, all fonts scale, and output resolution is phenomenal. Physical space, on the other hand, is the real world of devices, with limited color, strange output formats, and differing drawing capabilities. In Windows, an application does not need to understand the quirkiness of a new device. GDI code works on the new device if the device has a device driver.
GDI concepts mapped between the logical and the physical are objects (pens, brushes, fonts, palettes, and bitmaps), output primitives, and coordinates.
Objects are converted from logical objects to physical objects using the realization process. For example, an application creates a logical pen by calling CreatePen with the appropriate parameters. When the logical pen object is selected into a device context (DC) using SelectObject , GDI realizes the pen into a physical pen object that is used to communicate with the device. GDI passes the logical object to the device, and the device creates a device-specific object containing device-specific information. During realization, requested (logical) color is mapped to available colors, fonts are matched to the best available fonts, and patterns are prepared for output. Font selection is more complex than other realizations, and GDI, not the driver, performs most of the realization work. Similarly, palette realization (done at RealizePalette time as opposed to SelectPalette time) is done entirely within GDI. Bitmaps are an exception to the object realization process; although they have the device-independent bitmap (DIB) logical form, bitmap objects are always device specific and are never actually realized.
Output primitives are similarly passed as "logical" requests (to stretch the definition) to the device driver, which draws the primitive to the best of its ability and resolution. If the driver cannot handle a certain primitive—for example, it cannot draw an ellipse—GDI simulates the operation. For an Ellipse call, GDI calculates a polygon that represents a digitized ellipse. The resulting polygon can then be simulated as a polyline and a series of scanline fills if the device cannot draw polygons itself. The application, though, does not care what system component does the actual work; the primitive gets drawn.
An application can set up for itself any logical coordinate system, using SetMapMode, SetWindowExt , SetWindowOrg , SetViewportExt , and SetViewportOrg. In GDI that coordinate system is mapped to the device coordinate system, in which one unit equals one pixel and (0,0) defines the topmost, leftmost pixel on the output surface. The device driver sees only coordinates in its own space, whereas the application operates only in a coordinate space of its own, disregarding the physical pixel layout of the destination.
By maintaining the two separate but linked spaces, logical for the applications and physical for the devices, GDI creates a device-independent interface. Applications that make full use of the logical space and avoid device-specific assumptions can expect to operate successfully on any output device.
13.2 GDI Objects and its API’s
This topic will discuss Graphics Device Objects and the API ‘s used to create, select, get, release, draw and delete GDI objects.
GDI objects Creation
Each type of object has a routine or a set of routines that is used to create that object.
Pens are created with the CreatePen and the CreatePenIndirect functions. An application can use either function to define three pen attributes: style, width, and color. The background mode during output determines the color (if any) of the gaps in any nonsolid pen. The PS_INSIDEFRAME style allows dithered wide pens and a different mechanism for aligning the pen on the outside of filled primitives.
Brushes are created with the CreateSolidBrush, CreatePatternBrush, CreateHatchBrush, CreateDIBPatternBrush, and CreateBrushIndirect functions. Unlike other objects, brushes have distinct types that are not simply attributes. Hatch brushes are special because they use the current background mode (set with the SetBkMode function) for output.
Fonts are created with the CreateFont and CreateFontIndirect functions. An application can use either function to specify the 14 attributes that define the desired size, shape, and style of the logical font.
Bitmaps are created with the CreateBitmap, CreateBitmapIndirect, CreateCompatibleBitmap, and CreateDIBitmap functions. An application can use all four functions to specify the dimensions of the bitmap. An application uses the CreateBitmap and CreateBitmapIndirect functions to create a bitmap of any color format. The CreateCompatibleBitmap and CreateDIBitmap functions use the color format of the device context. A device supports two bitmap formats: monochrome and device-specific color. The monochrome format is the same for all devices. Using an output device context (DC) creates a bitmap with the native color format; using a memory DC creates a bitmap that matches the color format of the bitmap currently selected into that DC. (The DCs color format changes based on the color format of the currently selected bitmap.)
before it passes a normal pattern brush to the device driver. The selection of a DIB pattern brush with a two-color DIB and DIB_RGB_COLORS into a monochrome DC is a special case; GDI forces the color table to have black as index 0 and white as index 1 to maintain foreground and background information. The device driver turns hatched brushes into pattern brushes using the specified hatch scheme; the foreground and background colors at the time of selection are used for the pattern. All brush types can be represented at the device-driver level as bitmaps (usually 8-by-8) that are repeatedly blted as appropriate. To allow proper alignment of these bitmaps, GDI realizes each physical brush with a brush origin. The default origin is (0,0) and can be changed with the SetBrushOrg function (discussed in more detail below).
The GDI component known as the font mapper examines every physical font in the system to find the one that most closely matches the requested logical font. The mapper penalizes any font property that does not match. The physical font chosen is the one with the smallest penalty. The possible physical fonts that are available are raster, vector, TrueType fonts installed in the system, and device fonts built into or downloaded to the output device. The logical values for height and width of the font are converted to physical units based on the current mapping mode before the font mapper examines them.
Selecting a bitmap into a memory DC involves nothing more than performing some error checking and setting a few pointers. If the bitmap is compatible with the DC and is not currently selected elsewhere, the bits are locked in memory and the appropriate fields are set in the DC. Most GDI functions treat a memory DC with a selected bitmap as a regular device DC; only the device driver acts differently, based on whether the output destination is memory or the actual device. The color format of the bitmap defines the color format of the memory DC. When a memory DC is created with CreateCompatibleDC, the default monochrome bitmap is selected into it, and the color format of the DC is monochrome. When an appropriate color bitmap (one whose color resolution matches that of the device) is selected into the DC, the color format of the DC changes to reflect this event. This behavior affects the result of the CreateCompatibleBitmap function, which creates a monochrome bitmap for a monochrome DC and a color bitmap for a color DC.
Palettes are not automatically realized during the selection process. The RealizePalette function must be explicitly called to realize a selected palette. If a palette is realized on a nonpalette device, nothing happens. On a palette device, the logical palette is color- matched to the hardware palette to get the best possible matching. Subsequent references to a color in the logical palette are mapped to the appropriate hardware palette color.
Nothing is actually realized when a clip region is selected into a DC. A copy of the region is made and placed in the DC. This new clip region is then intersected with the current visible region (computed by the system and defining how much of the window is visible on the screen), and the DC is ready for drawing. Calling SelectObject with a region is equivalent to using the SelectClipRgn function.
Memory Usage
The amount of memory each object type consumes in GDIs heap and in the global memory heap depends on the type of the object.
This topic is discussed in Microsoft Documentation 2003 Release.
The following table describes memory used for storing logical objects.
Object type GDI heap use (in bytes) Global memory use (in bytes)
Pen 10 + sizeof(LOGPEN) 0
Brush 10 + sizeof(LOGBRUSH) + 6 0
pattern brush same as brush + copy of bitmap
Font 10 + sizeof(LOGFONT) 0
Bitmap 10 + 18 32 + room for bits
Palette 10 + 10 4 + (10 * num entries)
rectangular region 10 + 26 0
solid complex region rect region + (6 * (num scans –1)) 0
region with hole region + (2 * num scans with hole) 0
When an object is selected into a DC, it may have corresponding physical (realized) information that is stored globally and in GDIs heap. The table below details that use. The size of realized versions of objects that devices maintain is determined by the device.
Object type GDI heap use (in bytes) Global memory use
pen 10 + 8 + device info 0
brush 10 + 14 + device info 0
font 55 (per realization) font data (per physical font)
bitmap 0 0
palette 0 0
region intersection of region with visible region
As a result of the font caching scheme, several variables determine how much memory a realized font uses. If two logical fonts are mapped to the same physical font, only one copy of the actual font is maintained. For TrueType fonts, glyph data is loaded only upon request, so the size of the physical font grows (memory permitted) as more characters are needed. When the font can grow no larger, characters are cached to use the available
application is not responsible for deleting the object after use. Calling the DeleteObject function with a stock object does nothing.
Several stock fonts are defined in the system, the most useful being SYSTEM_FONT. This font is the default selected into a DC and is used for drawing the text in menus and title bars. Because this object defines only a logical font, the physical font that is actually used depends on the mapping mode and on the resolution of the device. A screen DC with a mapping mode of MM_TEXT has the system font as the physical font, but if the mapping mode is changed or if a different device is used, the physical font is no longer guaranteed to be the same. A change of behavior for Windows version 3.1 is that a stock font is never affected by the current mapping mode; it is always realized as if MM_TEXT were being used. Note that a font created by an application as a copy of a stock font does not have this immunity to scaling.
No stock bitmap in the system is accessible by means of the GetStockObject function, but GDI uses a default one-by-one monochrome bitmap as a stock object. This default bitmap is selected into a memory DC during creation of that DC. The bitmaps handle can be obtained by selecting a bitmap into a freshly minted memory DC; the return value from the SelectObject function is the stock bitmap.
Error Handling
The two common types of errors associated with objects are failure to create and failure to select. Both are most commonly associated with low-memory conditions.
During the creation process, GDI allocates a block of memory to store the logical object information. When the heap is full, applications cannot create any more objects until some space is freed. Bitmap creation tends to fail not because GDIs heap is full but because available global memory is insufficient for storing the bits themselves. Palettes also have a block of global memory that must be allocated by GDI to hold the palette information. The standard procedure for handling a failed object creation is to use a corresponding stock object in its place, although a failed bitmap creation is usually more limiting. An application usually warns the user that memory is low when an object creation or selection fails.
Out-of-memory conditions can also occur when a physical object is being realized. Realization also involves GDI allocating heap memory, and realizing fonts usually involves global memory as well. If the object was realized in the past for the same DC, new allocation is unnecessary (see the "Creating vs. Recreating" section). If a call to SelectObject returns an error (0), no new object is selected into the DC, and the previously selected object is not deselected.
Another possible error applies only to bitmaps. Attempting to select a bitmap with a color format that does not match the color format of the DC results in an error. Monochrome bitmaps can be selected into any memory DC, but color bitmaps can be selected only into a memory DC of a device that has the same color format. Additionally, bitmaps can be selected only into memory DCs; they cannot be selected into a DC connected to an actual output device or into metafile DCs.
Some object selections do not fail. Selecting a default object (WHITE_BRUSH, BLACK_PEN, SYSTEM_FONT, or DEFAULT_PALETTE stock objects) into a screen DC or into a screen-compatible memory DC does not fail when the mapping mode is set to MM_TEXT. Also, a bitmap with a color format matching a memory DC always successfully selects into that DC. Palette selection has no memory requirements and always succeeds.
Deletion of GDI Objects
All applications should delete objects when they are no longer needed. To delete an object properly, first deselect it from any DC into which it was previously selected. To deselect an object, an application must select a different object of the same type into the DC. Common practice is to track the original object that was selected into the DC and select it back when all work is accomplished with the new object. When a region is selected into a DC with the SelectObject or SelectClipRgn function, GDI makes a copy of the object for the DC, and the original region can be deleted at will.
hNewPen = CreatePen(1, 1, RGB(255, 0, 0));
if (hNewPen) //if the new pen is selected then ok else do
{ hOldPen = SelectObject(hDC, hNewPen);
}
else
hOldPen = NULL; // no selection
Rectangle(hDC,x,y,ex,ey) // drawing operations
if (hOldPen)
SelectObject(hDC, hOldPen); // deselect hNewPen (if selected)
if (hNewPen)
DeleteObject(hDC, hNewPen); // delete pen if created
An alternative method is to select in a stock object returned from the GetStockObject
function. This approach is useful when it is not convenient to track the original object. A
DC is considered "clean" of application-owned objects when all currently selected objects
are stock objects. The three exceptions to the stock object rule are fonts (only the
SYSTEM_FONT object should be used for this purpose); bitmaps, which do not have a
stock object defined (the one-by-one monochrome stock bitmap is a constant object that
is the default bitmap of a memory DC); and regions, which have no stock object and have
no need for one.
If, on the other hand, the brush is currently selected into a DC, calling the SetBrushOrg
function alone accomplishes nothing. Because the new origin does not take effect until
the brush is realized anew, the application must force this re-realization by using the
UnrealizeObject function before the brush is reselected into a DC. The following sample
code changes the origin of a brush that is initially selected into a DC:
// Deselect the brush from the DC.
hBrush = SelectObject(hDC, GetStockObject(BLACK_BRUSH));
// Set a new origin.
SetBrushOrg(hDC, X, Y);
// Unrealize the brush to force re-realization.
UnrealizeObject(hBrush);
// Select (and hence re-realize) the brush.
SelectObject(hDC, hBrush);
The UnrealizeObject function can also be called for a palette object, although the effect is
a bit more subtle. (As is common with the palette functions, nothing happens on a
nonpalette device.) The function forces the palette to be realized from scratch the next
time the palette is realized, thereby ignoring any previous mapping. This is useful in
situations in which an application expects that the palette will realize differently the next
time around, perhaps matching more effectively with a new system palette and not
forcing a system palette change. Any bitmaps created with the original realization of the
palette are no longer guaranteed to be valid.
Special Cases
Palette objects are selected into DCs using the SelectPalette function. The reason for this additional, seemingly identical, function is that palette selection has an additional parameter that defines whether the palette is being selected as a foreground or as a background palette, which affects palette realization on palette devices. Calling the SelectObject function with a palette returns an error. Palettes are deleted using the DeleteObject function.
A clip region can be selected into a DC by calling either the SelectClipRgn or the SelectObject function. Both functions perform identically with the exception of selecting a NULL handle in place of a region. SelectClipRgn can be used to clear the current clipping state by calling the function as follows:
Note: Parameter description of the API’s used above, can be best found from Microsoft
site, or contact Virtual University resource.
13.3 GDI from the Driver’s Perspective ( for advanced users )
Note: The documentation depicted below is for the advanced readers or those who are interested to know more about GDI driver model. Novice can skip this topic.
GDI is the intermediary support between a Windows NT-based graphics driver and an
application. Applications call Win32 GDI functions to make graphics output requests.
These requests are routed to kernel-mode GDI. Kernel-mode GDI then sends these
requests to the appropriate graphics driver, such as a display driver or printer driver.
Kernel-mode GDI is a system-supplied module that cannot be replaced.
GDI communicates with the graphics driver through a set of graphics device driver
interface (graphics DDI) functions. These functions are identified by their Drv prefix.
Information is passed between GDI and the driver through the input/output parameters of
these entry points. The driver must support certain DrvXxx functions for GDI to call. The
driver supports GDI's requests by performing the appropriate operations on its associated
hardware before returning to GDI.
GDI includes many graphics output capabilities in itself, eliminating the need for the
driver to support these capabilities and thereby making it possible to reduce the size of
the driver. GDI also exports service functions that the driver can call, further reducing the
amount of support the driver must provide. GDI service functions are identified by their
Eng prefix, and functions that provide access to GDI-maintained structures have names in
the form XxxOBJ_Xxx.
The following figure shows this flow of communication.
Display Device Context Defaults
Upon first creating a display device context, the system assigns default values for the attributes (that is, drawing objects, colors, and modes) that comprise the device context. The following table shows the default values for the attributes of a display device context.
Attribute Default value
Background color Background color setting from Control Panel (typically, white).
Background mode OPAQUE
Bitmap None
Brush WHITE_BRUSH
Brush origin (0,0)
Clipping region Entire window or client area with the update region clipped, as appropriate. Child and pop-up windows in the client area may also be clipped.
Palette DEFAULT_PALETTE
Current pen position (0,0)
Device origin Upper left corner of the window or the client area.
Drawing mode R2_COPYPEN
Font SYSTEM_FONT
Inter character spacing 0
Mapping mode MM_TEXT
Pen BLACK_PEN
Polygon-fill mode ALTERNATE
Stretch mode BLACKONWHITE
Text color Text color setting from Control Panel (typically, black).
Viewport extent (1,1)
Viewport origin (0,0)
Window extent (1,1)
Window origin (0,0)
An application can modify the values of the display device context attributes by using selection and attribute functions, such as SelectObject , SetMapMode , and SetTextColor.
For example, an application can modify the default units of measure in the coordinate system by using SetMapMode to change the mapping mode.
Changes to the attribute values of a common, parent, or window device context are not permanent. When an application releases these device contexts, the current selections, such as mapping mode and clipping region, are lost as the context is returned to the cache. Changes to a class or private device context persist indefinitely. To restore them to their original defaults, an application must explicitly set each attribute.
Common Display Device Context
A common device context is used for drawing in the client area of the window. The system provides a common device context by default for any window whose window class does not explicitly specify a display device context style. Common device contexts are typically used with windows that can be drawn without extensive changes to the device context attributes. Common device contexts are convenient because they do not require additional memory or system resources, but they can be inconvenient if the application must set up many attributes before using them.
The system retrieves all common device contexts from the display device context cache.
An application can retrieve a common device context immediately after the window is created. Because the common device context is from the cache, the application must always release the device context as soon as possible after drawing. After the common device context is released, it is no longer valid and the application must not attempt to draw with it. To draw again, the application must retrieve a new common device context, and continue to retrieve and release a common device context each time it draws in the window. If the application retrieves the device context handle by using the GetDC function, it must use the ReleaseDC function to release the handle. Similarly, for each BeginPaint function, the application must use a corresponding EndPaint function.
When the application retrieves the device context, the system adjusts the origin so that it aligns with the upper left corner of the client area. It also sets the clipping region so that output to the device context is clipped to the client area. Any output that would otherwise appear outside the client area is clipped. If the application retrieves the common device context by using BeginPaint , the system also includes the update region in the clipping region to further restrict the output.
When an application releases a common device context, the system restores the default values for the attributes of the device context. An application that modifies attribute values must do so each time it retrieves a common device context. Releasing the device context releases any drawing objects the application may have selected into it, so the application need not release these objects before releasing the device context. In all cases, an application must never assume that the common device context retains non default selections after being released.
coordinates of the area to erase and passes these coordinates to the FillRect function. Applications that process these messages can use similar techniques. The system supplies a window device context with the WM_ICONERASEBKGND message regardless of whether the corresponding window has a private device context.
An application can use the GetDCEx function to force the system to return a common device context for the window that has a private device context. This is useful for carrying out quick touch-ups to a window without changing the current values of the attributes of the private device context.
Class Display Device Context
By using a class device context, an application can use a single display device context for every window belonging to a specified class. Class device contexts are often used with control windows that are drawn using the same attribute values. Like private device contexts, class device contexts minimize the time required to prepare a device context for drawing.
The system supplies a class device context for a window if it belongs to a window class having the CS_CLASSDC style. The system creates the device context when creating the first window belonging to the class and then uses the same device context for all subsequently created windows in the class. Initially, the class device context has the same default values for attributes as a common device context, but the application can modify these at any time. The system preserves all changes, except for the clipping region and device origin, until the last window in the class has been destroyed. A change made for one window applies to all windows in that class.
An application can retrieve the handle for the class device context by using the GetDC function any time after the first window has been created. The application can keep and use the handle without releasing it because the class device context is not part of the display device context cache. If the application creates another window in the same window class, the application must retrieve the class device context again. Retrieving the device context sets the correct device origin and clipping region for the new window. After the application retrieves the class device context for a new window in the class, the device context can no longer be used to draw in the original window without again retrieving it for that window. In general, each time it must draw in a window, an application must explicitly retrieve the class device context for the window.
Applications that use class device contexts should always call BeginPaint when processing a WM_PAINT message. The function sets the correct device origin and clipping region for the window, and incorporates the update region. The application should also call EndPaint to restore the caret if BeginPaint hide it. EndPaint has no other effect on a class device context.
The system passes the class device context when sending the WM_ERASEBKGND message to the application, permitting the current attribute values to affect any drawing carried out by the application or the system when processing this message. The system
supplies a window device context with the WM_ICONERASEBKGND message regardless of whether the corresponding window has a class device context. As it could with a window having a private device context, an application can use GetDCEx to force the system to return a common device context for the window that has a class device context.
Note: Use of class device contexts is not recommended.
Window Display Device Context
A window device context enables an application to draw anywhere in a window, including the nonclient area. Window device contexts are typically used by applications that process the WM_NCPAINT and WM_NCACTIVATE messages for windows with custom nonclient areas. Using a window device context is not recommended for any other purpose.
An application can retrieve a window device context by using the GetWindowDC or GetDCEx function with the DCX_WINDOW option specified. The function retrieves a window device context from the display device context cache. A window that uses a window device context must release it after drawing by using the ReleaseDC function as soon as possible. Window device contexts are always from the cache; the CS_OWNDC and CS_CLASSDC class styles do not affect the device context.
When an application retrieves a window device context, the system sets the device origin to the upper left corner of the window instead of the upper left corner of the client area. It also sets the clipping region to include the entire window, not just the client area. The system sets the current attribute values of a window device context to the same default values as a common device context. An application can change the attribute values, but the system does not preserve any changes when the device context is released.
Parent Display Device Context
A parent device context enables an application to minimize the time necessary to set up the clipping region for a window. An application typically uses parent device contexts to speed up drawing for control windows without requiring a private or class device context. For example, the system uses parent device contexts for push button and edit controls. Parent device contexts are intended for use with child windows only, never with top-level or pop-up windows.
An application can specify the CS_PARENTDC style to set the clipping region of the child window to that of the parent window so that the child can draw in the parent. Specifying CS_PARENTDC enhances an application's performance because the system doesn't need to keep recalculating the visible region for each child window.
Attribute values set by the parent window are not preserved for the child window; for example, the parent window cannot set the brush for its child windows. The only property preserved is the clipping region. The window must clip its own output to the limits of the window. Because the clipping region for the parent device context is identical to the
the bounding rectangle as the application uses the specified display device context. The application can retrieve the current bounding rectangle at any time by using the GetBoundsRect function. The application stops the accumulation by calling SetBoundsRect again, specifying the DCB_DISABLE value.
13.5 Steps involved in output of a text string in the client area of
the application
The following points are adopted to output a text string.
- Get the handle to the Device Context for the window’s client area from the GDI.
- Use the Device Context for writing / painting in the client area of the window.
- Release the Device context.
Printing Text String (Example)
HDC hdc;
hdc = GetDC(hWnd); //Get the DC
char *str=”This is Gdi program”;
TextOut(hdc,10,10,str , strlen(str)); //output a text
ReleaseDC(hWnd,hdc); //release a DC
13.6 GetDC
The GetDC function retrieves a handle to a display device context (DC) for the client area of a specified window or for the entire screen. You can use the returned handle in subsequent GDI functions to draw in the DC.
hDC = GetDC( hWnd );
hWnd
Handle to the window whose DC is to be retrieved. If this value is NULL, GetDC retrieves the DC for the entire screen.
The GetDC function retrieves a common, class, or private DC depending on the class style of the specified window. For class and private DCs, GetDC leaves the previously assigned attributes unchanged. However, for common DCs, GetDC assigns default attributes to the DC each time it is retrieved. For example, the default font is System, which is a bitmap font. Because of this, the handle for a common DC returned by GetDC
does not tell you what font, color, or brush was used when the window was drawn. To determine the font, call GetTextFace.
Note: that the handle to the DC can only be used by a single thread at any one time.
After painting with a common DC, the ReleaseDC function must be called to release the DC. Class and private DCs do not have to be released. ReleaseDC must be called from the same thread that called GetDC. The number of DCs is limited only by available memory.
13.7 TextOut
The TextOut() function writes a character string at the specified location, using the currently selected font, background color, and text color.
BOOL TextOut( HDC hdc, // handle to DC int nXStart, // x-coordinate of starting position int nYStart, // y-coordinate of starting position LPCTSTR lpString, // character string int cbString // number of characters );
hdc is a HANDLE to the device context. nXStart: Specifies the x-coordinate, in logical coordinates, of the reference point that the system uses to align the string. nYStart: Specifies the y-coordinate, in logical coordinates, of the reference point that the system uses to align the string. lpString: Pointer to the string to be drawn. The string does not need to be zero- terminated, since cbString specifies the length of the string. cbString: Specifies the length of the string. For the ANSI function it is a BYTE count and for the Unicode function it is a WORD count. Note that for the ANSI function, characters in SBCS code pages take one byte each while most characters in DBCS code pages take two bytes; for the Unicode function, most currently defined Unicode characters (those in the Basic Multilingual Plane (BMP)) are one WORD while Unicode surrogates are two WORDs.
The interpretation of the reference point depends on the current text-alignment mode. An application can retrieve this mode by calling the GetTextAlign function; an application can alter this mode by calling the SetTextAlign function.
By default, the current position is not used or updated by this function. However, an application can call the SetTextAlign function with the fMode parameter set to TA_UPDATECP to permit the system to use and update the current position each time the application calls TextOut for a specified device context. When this flag is set, the system ignores the nXStart and nYStart parameters on subsequent TextOut calls.
