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.
CSS Units of Measure
|CSS Units of Measure|
||I found that a 20px font in CSS is not the same size as one in Java, even with the same font face.|
||Nominally one PostScript point. Postscript points are 1/72 inch. Printer points are 1/72.2 inch. Java points are 1 pixel. You really have to experiment to see the effect.|
||Usually used to defined font sizes. 2em means twice the size of the current font. Think of it as a size multiplier having
nothing to do with printer ems.|
||100% does nothing. 110% makes an element/font 10% bigger than it would normally be.|
||Even though this is nominally an absolute unit, it will rarely result is exactly 1 centimeter on screen or on the printed page.|
||Even though this is nominally an absolute unit, it will rarely result is exactly 1 millimeter on screen or on the printed page.|
||Even though this is nominally an absolute unit, it will rarely result is exactly 1 inch on screen or on the printed page.|
||height of the letter x in a font. Usually about half the font height. I don’t know how this is intended to be used. Perhaps it is for scaling margins.|
||12 points. 1/6 inch. There are five different definitions for pica in
The Wandering Font Size Problem
Font size is poorly defined. What determines the final size of type on your screen is
controlled by four factors.
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.
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.
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:
monospace, sans-serif and serif.
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.
- 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
- 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
- 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
- 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.
Oracle’s Javadoc on Font
class : available:
Oracle’s Javadoc on FontMetrics
class : available:
Oracle’s Technote Guide on Font Configuration Files