font size : Java Glossary

Introduction

Font size is slippery as a trout. I don’t think it is even formally defined. You pretty well have to experiment to find out what any given requested size results in, on any given browser, on any given font face, on any give platform. The results are different in CSS (Cascading Style Sheets) and Java. All you can truly count on is that requesting bigger font sizes will not result in smaller fonts.

CSS Units of Measure

CSS units of measure have to taken with a large grain of salt. Browsers have zoom features which can magnify or shrink. Printers have variable resolution. Tiny screens can now have as many dots as desktop screens. It is wise experiment with the various browsers, printers, devices, OSes to see the final effects. As a rule of thumb, avoid absolute units like px, pt, cm and inch as much as possible and use % or em.

The Wandering Font Size Problem

1. The font designer

   A nominally 10-point type can be tiny or huge. It depends on the whim of the artist who designed the font. The nominal font size has little to do with the height in pixels of some letter of the alphabet. For example TiresiasPCFont-Z is huge whereas KodchiangUPC is tiny.

2. Windows

   There is a setting in the control panel ⇒ Personalisation ⇒ Adjust Font Size DPI (Dots Per Inch) to globally adjust font sizes to accommodate visual acuity. This does not work very well since most Windows apps use bigger fonts but don’t correspondingly adjust the dialog boxes bigger to hold them.

3. Browser and CSS

   For example, in the Opera and Chrome browsers there is a Zoom command to zoom in and out making the type bigger or smaller. CSS has the further complication of default fonts which could be implemented by different physical fonts with different font metrics on different platforms: cursive, fantasy, monospace, sans-serif and serif.

4. Java

   When Applets select a font size, the JRE (Java Runtime Environment) scales the font to a corresponding number of pixels tall. In Windows, this overrides the browser and the operating system, but not the font designer. Java has the further complication of logical fonts which could be implemented by different physical fonts with different font metrics on different platforms: Dialog, DialogInput, Monospaced, SansSerif and Serif.

The problem is when CSS or Java substitutes a font for the one used to design and suddenly the layout is unusable because the replacement font, nominally the same size, is actually much larger or smaller.

The same problem bedevils word processors, but there the operator usually notices the problem and manually adjusts.

Proposed Fixes

• We should measure the true size of the font and use that in place of the size the designer supplied. There should be some objective math to measure true font size. This size should be embedded in the font.
• Perhaps the OS (Operating System) could measure the true font size when it installs and font and substitute the true size.
• Perhaps we could write a utility that sniffs out all the fonts on your system, measures them and patches them with the true size. This would fix the problem for word processors too. The only problem is if you used any CSS or Java composed elsewhere, it would presume the unadjusted sizes and you would be back where you started, but in the opposite direction.
• Failing that, you should be permitted to assign a normalising factor for each font face both to CSS and to Java. It could be defined as the true size of a nominally 10 point font. Alternatively it could be defined as a fraction to multiply the nominal point size to get the true font size. Then you do your CSS and Java programming using true font sizes. By tweaking these fudge factors you could still choose to use slightly larger or small fonts than the strict math would suggest.

Fixes For CSS

What sort of syntax could you introduce into CSS so that you could use either the old size system or the new and still be upwardly compatible?

• You might add a field size-adjust to the @font-face and allow it to logically modify the sizes of already installed fonts.
• You might invent a new size unit, the true point tpt.
• You might allow an adjustment factor to be attached to each font face in the font-face property separated from it by a :

Fixes For Java

What sort of solution might you provide for Java?

• Add an optional final Boolean parameter to the Font constructor, when true, it means the size is in true points, ditto for derivefont and getSize. Perhaps it the parameter could be a fudge factor to use if the system does not already have one on tap.
• You still need a way to define the fudge factors for all the font faces/fonts you use. All it has to be is a csv file with font name, then fudge factor one per line. But it has to be somewhere, perhaps massaged into a binary or serialised object, so java.exe will know to load it.
• Java could handle this automatically by computing the true font size of any font it encounters and caching it. It could be preloaded with the true sizes of the net’s most common fonts.
• I put code in all my Java GUI (Graphic User Interface) applications that checks a list of desirable fonts to see what is available, then it adjusts the one it chooses with an adjustment factor for that font hard coded into the app.

• You could write a FontFactory class that provided the following services:

  • Like CSS, you provide a list of font faces and it picks the first font that is installed.
  • A method that measures the true size of a Font.
  • A factory method that provides you with a Font given a list of font faces and true Font size. It caches as appropriate.
  • A method for choosing different fonts depending on the hosting OS.

  You are welcome to cannibalise and generalise any code in FontShower and BestFont, part of the common18 package.

Learning More