This document has not been updated in over a decade and is severely out of date. I have kept it available for historical interest only.

Points are often mistakenly thought as pixel units. Points are not pixel units. Points are physical lenght units. In CSS and in PostScript there are 72 points in one inch. Defining the font size in points on Web pages is considered harmful.

History

Over a decade ago the early Macintoshes had 9" black&white displays with pixel dimensions of 512*384. The ppi (pixels per inch) of the display was close to 72 and the operating system used that value to convert physical measures—inches, points, centimeters etc.—to pixel measures. It was a time of real WYSIWYG. The measures were right and there was no color and, therefore, no miscalibrated colors.

Later on, Macs got larger displays with higher resolutions. However, the assumption about 72 ppi stuck in software. In fact, if you buy the latest and greatest video card and plug in a large screen and run it at 1600*1200, Apple System Profiler will tell you that the dpi (it says dpi, not ppi) of the display is 72. Mac OS has no idea of the true resolution of the screen. It still uses the value that was true for the first Macs.

The Real Resolution

Nowadays the real resolution is different. For example, an iMac with screen set to 1024*768 has a screen resolution of 91 ppi. Apple’s beige 17" AppleVision/ColorSync displays (with a tube by Sony) have a ppi of 98 at 1280*960 (when configured optimally). It is true that the Mac OS and almost all Mac applications still assume 72 ppi in their unit conversions, but as you can see, the assumption is seriously flawed.

The real ppi of the screen is easy to measure. Just divide the pixel dimensions of the screen with the physical dimensions (in inches) of the screen. The horizontal ppi and the vertical ppi should be closely the same unless you are using the 1280*1024 mode. (Using the 1280*1024 mode instead of the 1280*960 mode is a bad idea, because on a normal screen with aspect ratio of 4/3 the pixels are not square when using the 1280*1024 mode.)

A display with 72 ppi at 640*480 would have a visible area of about 23 cm (8.9") by 17 cm (6.7"). That would be close to a 14" screen.

Microsoft’s default guess is 96 ppi. Until recently, the real resolution of screens sold with PCs has been lower than that. For example, if a Windows machine has a 17" screen at 1024*768, the resolution of the screen is 80 ppi or less.

A display with 96 ppi at 640*480 would have a visible area of about 17 cm (6.7") by 13 cm (5.0"). Now that would be one small screen.

The Consequences

Now the Windows user with the real ppi at 80 sets the point sizes of fonts smaller to compensate for the assumption of 96 ppi. Mac OS, on the other hand, assumes a ppi smaller than the actual ppi. As a result, the text on the Mac is fewer pixels tall and, in addition to that, the pixels are smaller!

While waiting for display hardware that reports the correct resolution to the OS, the false assumptions about the ppi could be corrected if a configuration wizard asked the user to measure the screen as a part of the set-up process of the OS.

Since operating systems aren’t there yet, the issue needs to be handled at the application level for the time being.

Impact on CSS and the Web

The assumptions about the pixel size of a point are seriously flawed in many browsers and all browsers cannot be configured properly. An author should make no assumptions about the pixel size of something defined in points.

Even if most browsers were configured properly, it would still be a better idea to use font sizes relative to the preferred font size set by the user. Long passages of text, ie. text within <p> elements, should be left at the users preferred size by leaving the font size undefined. The font size of headers and captions should be set relative to the preferred size using percentages.

Some authors will argue that their pages need to presented with fonts at a particular pixel size. It is important to remember that pages are intended for a user to read. It is, therefore, the user who knows best which size is good.

If an author still wants to set the font size to a particular pixel size, using points is the wrong way to do the wrong thing. If you mean pixels, use the pixel unit (px in CSS).

Impact on WYSIWYG in paper publishing applications

If the physical resolution of the screen and the logical resolution of the screen don’t match, the 100% zoom level in paper publishing apps does not display the page in natural size. To fix this, set the zoom factor to the ratio of the physical resolution and the logial resolution. If the physical resolution is 91 ppi and the logical resolution is 72 ppi, zoom to 126%.

After zooming, the font sizes may not match the sizes of the bitmap fonts available on the system. To increase the quality of font rendering, use anti-aliasing. Adobe Type Manager can anti-alias Type 1 fonts on Mac OS. SmoothType can anti-alias TrueType fonts on Mac OS. The results achieved with SmoothType are significantly better than the results achieved using the built in so called anti-aliasing in Mac OS Classic.

Answers to related Frequently Asked Questions

Does IE 5 for Mac ignore sizes defined in points?

No, it does not. Neither does Mozilla.

Does IE 5 for Mac render point-sized text incorrectly?

If the ppi value in the browser preferences is correctly set, point-sized text is rendered correctly. The same applies to Mozilla.

Compared to other browsers, does IE 5 for Mac render point-sized text differently?

Other browsers have more than one way of doing things. IE 5 for Mac can be configured to match the point size handling of a particular other browser but not all of them at the same time. The same applies to Mozilla.