The Exact Relationship between Font Family,

Letter Spacing, Word Spacing, Font Size and the

Pixel Length of an Arbitrary Text String on the

World Wide Web

The Starting Fact: String Pixel Length is Linear in Font

SizeThe first thing to understand is that for constant values of font-family, letter spacing, word spacing the text string length in pixels increases linearly with font-size. For example: Run the fontStats program:

( http://nosetothepage.org/fontStats/FDSDoc.html ).

Set the author’s font to (Verdana, 16px, 0.12em, 0.16em) and the user’s font to (Verdana, 48px, 0.12em, 0.16em) and you will get a width ratio of 3.003. The sample text is 1109px long for the author (font-size=16px) and 3330px for the user (font-size=48px). Given a little variation in how browsers measure width using the runtime method document.getComputedStyle(string).width, the fact that our string length only varies from 3=48/16 by 0.003 means we are close enough. Try it with lots of settings. Just remember that your vector should only vary in font-size.

There is of course a reason. All terms are computed in terms of constants times font-size. For example, the default letter-spacing

is a constant k[c]*fontSize for each character c. If we add to the default spacing say 0.12em, we just add 0.12*fontSize to the default letter spacing. Word spacing is just a linear function of letter-spacing and so on. There are too many constants to keep track of by hand. That’s why I wrote fontStats. It keeps track for us.

16 Pixels is the Pivot for Font-SizeThe standard EM value 16px acts like 12-point font on paper if you read from the expected reading distance for your device. That is, you hold your mobile phone close and you sit back for your desktop. The fact that 16px is smaller on the mobile accounts for the fact that we hold it closer than we view a desktop monitor. 12-point on paper works the same. We hold the paper at 16 inches on the average giving us an image on our retina that is the same as the image on our retina induced by 16px on a mobile or desktop monitor.

This font size is optimal for normal readers (readers that are within one standard deviation from 20/20 in feet or 6/6 in meters). Now, the smallest size a person can read comfortably actually is a little smaller. On paper, it runs around 10pt 1pt depending on font family. That means 14px font on a device will be about 10.5pt, safely within the range of comfortable reading.

This means that font size can be varied a little from 16px to shorten the length of character strings without impacting the

readability significantly. For low vision, we just enlarge the modified font size by 200%, 300% or 400% to get a readable resulting text string even if the starting point has had its font-size reduced. The zoom is distributed linearly so that the resulting text string is readable in the same way it is for a fully sighted reader.

The Text Adjustment ProblemTo read text, people with low vision, change typographic parameters. This creates a problem for web development. Developers make fields that require certain sizes to fit layout constraints. There is little flexibility possible to meet these layout requirements. Note: This discussion does not consider significant enlargement. That requires dramatic readjustment of layout. That is another problem that needs a responsive approach.

In this essay, I am discussing text adjustments that must be valid at all zoom levels. These adjustments include changing font family, letter spacing and word spacing. There are also minor adjustments of font size described above. I call these the small adjustments. A small adjustment of text that fits in a bounding box without zooming, will still fit in the enlarged box after a big zoom.

Zoom of text acts like a change in font-size. We know text string length is linear in font size. Thus, I need only analyze the case where the base font is the pivot, 16px. For increased zoom, we extend our results by linearity.

The SolutionThe user needs to enlarge letter spacing and word spacing to read better. These changes will always enlarge the length of text. That means it will not fit in the intended boxes. This can be fixed with two parameters font-size as described above and font-family.

Keeping Font-Family ConstantSuppose our author uses the most popular Google Font, Roboto, with font size 16px, letter-spacing and word-spacing 0em above the default. We want to enlarge the letter and word spacings to 0.12em and 0.16em respectively. The result is the text width grows by 23.4%. That is way too much growth. I think 5% is about the right number. If we reduce the user’s font size to 14px, a safe reduction, Growth of the string length is 8%. A little bigger than I’d like. If we lower the font size to 13.5px we get a growth of 4%. We could also reduce the spacing a little. That is keep 14pt font with letter and word spacing 0.08 and 0.14 respectively. That gives a growth of 1.2%. The user can decide the tradeoffs.

Varying Font FamilyWhen font-family is in play we can choose a smaller but more readable font. Once again assume the author chooses (Roboto, 16px, 0em, 0em). If we start with (PT Sans, 16px, 0em, 0em) we see that we decrease the string size to 95.4%. We get room for play.

If we apply (PT Sans, 16px, 0.12em, 0.16em) for the user, the text only grows by 18.8%. At the setting (PT Sans, 14px, 0.12em, 0.16em) we only get a 4% increase. Good. At (PT Sans, 14.5px, 0.1em, 0.15em) we get a 4.1% increase. Still good. Let the user decide.

PT Sans is better for low vision because it is easy to distinguish capital I, lower case l and the digit 1 from each other. The pairs 5 and S as well as 0 and O are easily distinguished as well.

ConclusionThe font adaptation problem is solvable in a form that is reasonable for users and authors. There is more flexibility when font family substitution is enabled.

This solution only works if users and authors follow reasonable constraints. The user must limit string length variation resulting from all small adjustments to 5% or less. The author must enable the flexibility to support a variation of 5%. That seems like a reasonable compromise.

You can verify all these observations using the fontStats application.

Note: This solution is language independent. It works the same way with Chinese, Hebrew or Greek. Go ahead and plug in a string from your own language.