The Old Joel on Software Forum: Part 3 (of 5)

Metric Units on Windows

I have been attempting to display a grid, measured in millimeters, on the screen.

If you have ever tried this before you would soon discover that the grid is not quite perfect. I'm guessing this is because of the rounding errors that occur during display. Even when using the Windows mapping modes MM_LOMETRIC or MM_HIMETRIC, the grid is still not perfect.

It may also be because Windows measures the display in pixels per inch not pixels per (insert metric unit here).

I've come to the conclusion that it is impossible to display a nice even metric grid on a display device under Windows because it does not natively support the metric system but I thought I'd ask in case it is possible or in case anyone has run into this problem before and can offer some advice.

(*)Maybe someone could also point me to a resource that explains why Windows and physical devices measure units in "units per inch" rather than or in addition to "units per metric measure". I would guess the answer lies in the origins of the development of Windows, Printers and other devices and their need for backward compatibility.

* For example, it may be convenient if the screen device driver could change the screen format and report 96 pixels per inch or 20 pixels per centimeter. I don't know if this would require a hardware change or not. (i.e. Are monitors physically made to have 96 pixels per inch).

Dave B.
Wednesday, January 21, 2004

Monitors can be set to display multiple resolutions. Does that answer your question as to whether they're manufactured to show a certain number of pixels per inch? ;)

Sum Dum Gai
Thursday, January 22, 2004

You mean you undserstand all that mapping mode sh*t? You may be the only one. Or I may be the only one that doesn't.

Thursday, January 22, 2004

Twips

Twentieth of a point, this is 1/1440th of an inch and 1/567th of a centimetre. There are algorithms to convert from twips to pixels in the desired resolution, and whilst twips varies in physicial size on the screen depending on its resolution it will always be a twentieth of a point for printing purposes.

It seems there's a do it all digital ruler which I haven't used or have any experience of at http://www.basta.com/ProdReglo.htm

Simon Lucy
Thursday, January 22, 2004

MS is really screwy Metafiles are natively in 100ths of a millimetre. The print preview stuff I did a while ago may help you here (Must finish the notes section).

http://www.ibbotson.co.uk/vbprint/vbprinting.html

However when printing to Postscript printers the native mode is in points. The native screen resolution on most (it's changeable) windows machines is 96 dpi which if convert you it into twips gives a nice round 15 twips per pixel.

Peter Ibbotson
Thursday, January 22, 2004

Hrm... I guess it's hard for me to explain it any simpler than I have but I can try.

As Peter mentioned there are 15 twips per pixel on a 96 dpi screen.

1440 twips per inch / 96 pixels per inch = 15 twips per pixel.

Now let's try to determine how many twips there are per millimeter.

We know there are 96 pixels per inch and 25.4 millimeters per inch so we can now calculate how many pixels per millimeter.

96 pixels per inch / 25.4 millimeters per inch = 3.779527559 pixels per millimeter.

We know from our earlier calculation that there are 15 twips per pixel and 3.779527559 pixels per milleter.

15 twips per pixel * 3.779527559 pixels per millimeter = 56.69291339 twips per millimeter.

The result, 56.69291339 twips per millimeter is obviously not a nice round number like 1440 twips per inch and does not map nicely to 15 twips per pixel.

This is because the whole thing is based on inches and not millimeters (or whatever metric unit suits your fancy).

If Windows or the hardware (i'm not sure which is at fault) would instead provide separate modes for inches and millimeters so that they would report 96 dpi or X dpm (or something similar) then the calculations would turn out nice and even and would not suffer from rounding errors.