├── absoluteMeasurementDPI.md
├── different_sizes_measured.png
└── testPage.html
/absoluteMeasurementDPI.md:
--------------------------------------------------------------------------------
1 | # A 12pt Font Should Be The Same Size Everywhere: Time to Get Serious About Resolution Independence
2 |
3 | ## tl;dr
4 |
5 | Computer displays have reached high-enough pixel densities where the graphics and text rendered on them should be specified using absolute measurements such as inches or millimeters. Expedient excuses by the computing community to use current pixel-based measurements are just that: expedient. The visual mismatches when rendering computer graphics will only become more pronounced as user interfaces for ubiquitous computing take increasing advantage of multiple displays. We must return to the original design intent of resolution independent graphics to get the benefits of rendering them in a predictable fashion.
6 |
7 | ## The Problem in a Picture
8 |
9 | If you render the sentence "The quick brown fox jumped over the lazy dog." using 12 point Times Roman in a box that is specified to be 5 inches across in [HTML](testPage.html), you will likely observe the following:
10 |
11 | 
12 |
13 | The real-world definitions of inches and points (1 point = 1/72nd inch) get lost in translation when the final result shows up on a computer display. The following table describes what is actually observed:
14 |
15 |
16 |
17 | Model |
18 | Resolution |
19 | Diagonal Size (inches) |
20 | PPI |
21 | Actual direct-on-glass 5" measurement (inches) |
22 |
23 |
24 | Samsung SyncMaster 910T |
25 | 1280x1024 |
26 | 19 |
27 | 86.27 |
28 | 5.5625 |
29 |
30 |
31 | Apple iMac 27" |
32 | 2560x1440 |
33 | 27 |
34 | 108.79 |
35 | 4.4063 |
36 |
37 |
38 | Apple iPad 2 |
39 | 1024x768 |
40 | 9.7 |
41 | 131.96 |
42 | 4.8438 |
43 |
44 |
45 |
46 | ## How We Got Here
47 |
48 | Computer hardware and software people could never figure out a reliable way to communicate the diagonal display size. It was just easier for the hardware and software to communicate the screen resolution and just punt on factoring in how packed the pixels were when rendering computer graphics. There was never commitment by the computer industry to deliver display output that matched real-world measurements.
49 |
50 | ## "Told You So" - An Old Rant About Resolution Independent Computer Graphics
51 |
52 | The old argument is this: When [rasterizing](http://en.wikipedia.org/wiki/Rasterisation) computer graphics, the only sane APIs are those which faithfully support real-world measurements such as inches or millimeters. This argument for [resolution independence](http://en.wikipedia.org/wiki/Resolution_independence) has been around for a long time:
53 |
54 | * 1978 for TeX which introduced the device independent file format.
55 |
56 | * 1982 for PostScript which used real-world measurements by specifying a point to be 1/72nd of an inch.
57 |
58 | * 1987 for [DisplayPostscript](http://en.wikipedia.org/wiki/Display_PostScript) which unified an imaging model between printing and displaying to a screen.
59 |
60 | The advent of mass-market high density (≥160 Pixels Per Inch (PPI)) displays today has made designing user interfaces that work consistently across them a challenge. Add the fact that many of those displays are touch-enabled, then the argument to faithfully support real-world measurements in graphics APIs becomes even more compelling.
61 |
62 | *To do otherwise is just a hack.*
63 |
64 | A number of unnatural metrics for computer graphics to account for different displays have arisen, particularly in the mobile space:
65 |
66 | * [iOS points vs pixels](http://developer.apple.com/library/ios/#documentation/windowsviews/conceptual/viewpg_iphoneos/WindowsandViews/WindowsandViews.html)
67 |
68 | * [Android density-independent pixel (dp)](http://developer.android.com/guide/practices/screens_support.html)
69 |
70 | Both approaches above do not specify dimensions that map reliably to measurable units that humans can touch and see.
71 |
72 | ## We Need To Fix This Now
73 |
74 | The current approach to building user interfaces to support multiple display densities is neither sustainable nor fun. We are starting to conceive of and build deeply pervasive and ubiquitous computing applications that define interactions across multiple displays. To efficiently build such user interfaces, we need software and hardware that take into account display density.
75 |
76 | ## Yes, but…
77 |
78 | Expedient Excuses:
79 |
80 | * Legacy support. Too much code has been written using pixel dimensions.
81 |
82 | Moving to using points or dp is a step towards migrating away from pixels. What needs to be done next is to lock down the mapping of these units into real-world dimensions.
83 |
84 | * Too many different kinds of displays.
85 |
86 | Start implementing resolution independent graphics with displays that are 100 PPI or higher. (Prediction: in 5 years all new mobile handsets will have > 160 PPI screens.)
87 |
88 | * Font-hinting gets thrown under a bus.
89 |
90 | Font-hinting becomes less necessary at 200 PPI and higher. That said, resolution independent implementation of fonts at 100 PPI will still be a challenge but can be considered in the long term (say 10 years from now going forward) a short-term problem. Hardware vendors could relish at the thought of selling high density displays to replace existing ~100 PPI displays today.
91 |
92 | * Getting vendor consensus on specifications is too hard.
93 |
94 | You have to start somewhere, sometime. Having the hardware and software development community to understand that we can fix this problem *now* is a good place to start.
95 |
96 |
97 | ## It's Not Too Late
98 |
99 | Resolution independent graphics is a solved problem. My appeal is to software and hardware developers to ensure that a 12 point font will be rendered the same size everywhere, regardless of screen size and density. With high PPI displays we can deprecate the practice of using pixels to describe dimension. Solve this and then we can really have the fancy things we're seeing people imagine in the movies.
100 |
101 | ## "All of this has happened before, and it will all happen again."
102 |
103 | I'm writing this in the middle of July 2012. Where will this argument be in another 25 years?
104 |
105 | ## Links
106 |
107 | [Pixels Per Inch (PPI) Calculator](http://members.ping.de/~sven/dpi.html)
108 |
109 | ## Acknowledgments
110 |
111 | Thanks as follows:
112 |
113 | * Erica Sadun [@ericasadun](https://twitter.com/ericasadun) for encouraging me to write this.
114 |
115 | * Matt Conway [@ConwayMatt](https://twitter.com/ConwayMatt) for bouncing his informed thoughts on this matter.
116 |
117 | * Randy Pausch for his long-ago Computer Graphics lecture on scan conversion and his offhand remark that "PostScript got this right" when discussing resolution independence.
118 |
119 |
120 | ## Discuss
121 |
122 | Apparently this post has struck a nerve on both Hacker News and Reddit. Here are their links to add to the discussion:
123 |
124 | * [HN Discussion](http://news.ycombinator.com/item?id=4236429)
125 |
126 | * [Reddit Discussion](http://www.reddit.com/r/programming/comments/wi5r6/12pt_should_be_the_same_everywhere/)
127 |
128 |
--------------------------------------------------------------------------------
/different_sizes_measured.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kickingvegas/12pt-should-be-the-same-everywhere/a2c17a8395e62725066ddb3423b84ad942a5c6da/different_sizes_measured.png
--------------------------------------------------------------------------------
/testPage.html:
--------------------------------------------------------------------------------
1 |
2 |
3 | A 12pt Font Should Be The Same Size Everywhere
4 |
5 |
33 |
34 |
35 |
36 | Hello
37 |
38 |
39 |
The quick brown fox jumped over the lazy dog.
40 |
41 |
42 |
43 |
44 |
--------------------------------------------------------------------------------