Windows Coordinate System

The very fundamental coordinate system in Microsoft Windows OS that every PC user should know has the unit of “PIXELS”. This is known as the Device Coordinate System, or more specifically Display Device (Screen) Coordinate System. In fact, many a Windows programmer has come to know only this specific coordinate system.

The coordinate system originates from the top-left corner of the screen. The X-axis extends in the positive direction when going towards the right of the screen; while the Y-extends increases in the positive direction when going downwards the screen. The direction of the y-axis is thus flipped in the opposite direction compared to the Cartesian system that we are familiar with. A “pixel” is the smallest unit representable on the screen, and it is therefore the unit used for this coordinate system.

The number of pixels that can be displayed on the screen is also referred to as the screen’s real-estate. It also depends on the resolution settings. A larger resolution (eg: 1920 x 1080) will give you more screen real estate compared to a smaller resolution (eg: 1024 x 768). However, the graphics and fonts will appear smaller if a larger resolution is used. A Windows application can query the screen resolution using the WINAPI functions such as GetDeviceCaps(HORZRES) and GetDeviceCaps(VERTRES), which would give the width and height, in pixels, of the screen respectively.

The diagram showing the direction of x- and y-axis in the screen coordinate system

If your application only exists on the screen, that will be all you need to know. However, if you are dealing with real world dimensions, e.g: printing, I would like to introduce to you two new coordinate systems, which are the logical and physical coordinate systems.

The physical coordinate system corresponds to real world measurement units, which are gauged by two important set of standards, i.e the Metric system and the old Imperial system. The standard metric units are like millimeters, centimeters, meters, and kilometers; while the Imperial units are inch, foot, yards, and miles. The measurement values may contain floating-point values (or decimal values), e.g: 1/2 inch, 3.65cm, 1.8 miles, etc, since we can never expect real world measurements to be consisting of round values (or integers) only. Of course, these physical units are units that can be measured using physical tools, and their applications are almost seen everywhere –  trade, design, manufacturing, construction, aerospace and all sorts of engineering.

Today, almost every of the above industries uses software. It is really important that we could represent physical dimension on screen as accurately as how we could draw it on paper. Software needs to know physical dimensions.

The logical coordinate system is introduced not without reason. Back in the days when Windows 3.0 was first released, floating-point computing power is not as abundant as in today and some computers do not even have a floating-point coprocessor. Certainly, integer operations are more preferred and that is why all WinAPI functions specify integers as parameters. This includes all drawing and GDI-related calls. In order to overcome the limitation of representing physical units in integers, the logical units have come to be introduced.

The physical length that corresponds to a logical unit depends on the mapping mode used. Each device context (or drawing surface) in windows can be set to its own mapping mode.

Mapping mode	Meaning
MM_HIENGLISH	Each logical unit is mapped to 0.001 inch. Positive x is to the right; positive y is up.
MM_HIMETRIC	Each logical unit is mapped to 0.01 millimeter. Positive x is to the right; positive y is up.
MM_LOENGLISH	Each logical unit is mapped to 0.01 inch. Positive x is to the right; positive y is up.
MM_LOMETRIC	Each logical unit is mapped to 0.1 millimeter. Positive x is to the right; positive y is up.
MM_TEXT	Each logical unit is mapped to one device pixel. Positive x is to the right; positive y is down. (This is the default.)
MM_TWIPS	Each logical unit is mapped to one twentieth of a printer’s point (1/1440 inch, also called a twip). Positive x is to the right; positive y is up.

Now, an application can draw in physical dimensions, using the mapping mode defined by its own. The application also needs to store dimension data. It is thus necessary that the programmer recognize the coordinate system used for storing the data and maintain uniformity throughout his application in order to avoid confusion. Typically, only one set of coordinate system (physical or logical, but not device coordinates) will be used for the actual storing of data. The reason device coordinate system not being used is that the measurement is device-dependent.

With logical coordinate system, you can print out a perfect 3cm x 3cm square by setting the width and height to 300 x 300 logical units, assuming you are applying the MM_LOMETRIC mapping mode.

However, there is one caveat. Using logical coordinates will let you print out accurate dimensions on paper but on screen, it gives you proportional size but doesn’t guarantee accurate dimensions. Why would you need that after all? As long as the application display a virtual ruler containing the correct scale, you wouldn’t take a ruler to measure the dimension of an object on screen, or would you? Recall that Microsoft Word also features two sets of ruler (one vertical, one horizontal), and that would tell you the real measurements of every object on the document.

Another reasoning is that Windows knows nothing about the size of your screen. What it can do is basically assume the number of pixels that makes up a logical inch. Typical this value is set at 96, and in the unit dpi (dots per inch). Hence, if your screen has a resolution of 1280 x 800, Windows assume that your screen has a virtual size of (1280/96)” x (800/96)”  = 13.333″ x 8.333″, whereas in reality your screen might be smaller, e.g:10.25″ x 6.40″ . That’s why you couldn’t display real dimensions on screen. With printer, however, the dpi of the printer device itself is usually fixed at 600 dpi or 1200 dpi, thus Windows has no problem printing out an accurate dimensions.

Back to our topic on logical units, there is one more mapping mode worth mentioning, i.e: MM_TWIPS. Each logical unit is mapped to one twip, the equivalent of 1/20 point or 1/1440 inch.

1 pt = 1/72 inch

1 twip = 1/20 pt = 1/1440 inch

These units belongs to the units that describe font size, e.g: 12 pt . Thanks to Steve Job for taking calligraphy classes and introducing fonts in the first Macintosh computer, today we can have wonderful and attractive fonts in our computers.

Font Height Measurement

A font has several height attributes (as shown above). Try guess which attribute would represent the font size in points. Guessing net height? Yes, you’re right. Actually, The point size corresponds to the difference between tmHeight and tmInternalLeading, i.e net height. For instance, with the MM_TWIPS mapping mode in effect, a selected 12-point font might have a tmHeight value of 295 logical units and a tmInternalLeading value of 55. The font’s net height of 240 corresponds to the point size of 12 (since 12 pt = 240 twips).

After all, why should I dig myself into all these? There are many applications that simply fail to realize the relationship between the different coordinate systems. This causes the WYSINWYG (what you see is not what you get) problem- what you see on screen, you won’t definitely get it on printer. The hardest part is probably to handle the conversion between point size and pixels or  between point size and physical units. Therefore, when you are going to implement printing in your application next time, make sure you do it perfectly.