W3C home > Mailing lists > Public > www-style@w3.org > January 2000

font-size and font-size-adjust

From: Erik van der Poel <erik@netscape.com>
Date: Sat, 22 Jan 2000 16:03:14 -0800
Message-ID: <388A4542.387529FC@netscape.com>
To: www-style@w3.org
Hi again,

I have some ideas for improvement of the font-size and font-size-adjust
specs.

First, however, I'd like to thank Kent Karlsson for proposing
font-ex-size and for reminding us of the fact that fonts scaled to a
particular size based on their "em square" (or "designer's square") do
not always look the same size. CSS2 even admits this fact, in the
section on font-size-adjust.

However, font-ex-size will not work. When you start to think about how
this new property would interact with font-size and CSS's inheritance
model, you will see that it doesn't work.

An example should indicate this. Let's suppose that a user with poor
eyesight has a style sheet with the following:

  BODY { font-family: Verdana; font-ex-size: 20px; }

Suppose that the author has the following:

  P.fineprint { font-family: Times; font-size: xx-small; }

If P.fineprint inherits font-ex-size from the user's style sheet's BODY
rule, then P.fineprint will have 2 conflicting font sizes to choose from
(the font-size and the font-ex-size). Which one should it choose? It
would be nice if the user's desired font-ex-size was somehow reflected
in the actual value of the font size for P.fineprint. E.g. some sort of
factor would be nice.

This is why font-size-adjust is, or could be, superior. It is a *factor*
that is inherited by child elements.

However, the font-size-adjust spec talks about "first choice fonts" and
"substitute fonts". The wording seems to be referring to the font
matching algorithm's substitution stuff:

  http://www.w3.org/TR/REC-CSS2/fonts.html#font-size-props
  http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm

I think that it is too limiting to limit font-size-adjust to
substitution scenarios. It can be even more effectively used in
non-substitution scenarios. Let's change the example a bit. The user
says:

  BODY { font-family: Verdana; font-size: 24px; }

The author says:

  P.fineprint { font-family: Times; font-size: xx-small; }

The implementation looks up Verdana's "aspect" value, which is 0.58
according to the CSS2 spec's example. Then P.fineprint's font size is
determined first by looking up the value of xx-small relative to the
user's 24px specification, and then multiplying by the ratio of the 2
aspects, as specified in CSS2. I.e. Times has an aspect of 0.46, so we
multiply by 0.58/0.46.

In this way, it is possible to adhere to the user's chosen ex size,
which is the true subjective size of a font (according to CSS2 and
people on this mailing list).

However, for all of this to work, the aspects have to be calculated from
"real" values. The CSS2 spec currently says that the aspect value is
"font size divided by x-height". Not only is this definition reversed,
one of the values is inexact (font size). The problem with font-size, as
it is currently implemented in all(?) browsers, is that it is based on
the "em square" (or "designer's square"), which does not have a fixed
relationship with the actual glyphs. This relationship varies from font
to font.

So, my suggestion is to use the font's ascender or cap-height value as
the font-size. In some fonts, the glyphs themselves may have various
ascender and cap-height values, but hopefully the fonts will have some
sort of "nominal" ascender and/or cap-height value that could be used
for this. If not, I suppose the implementation could compute the median
of the ascents of the glyphs for letters with ascenders and capital
letters, respectively.

This way, we tie up the loose ends in the whole font size problem. The
problem was that so many things were floating around; there were many
variables; now we should be able to pin all of this down.

Of course, one of the remaining problems is what to do with unicameral
fonts (fonts that don't have separate upper and lower case letters).
Here, my suggestion is to limit font-size-adjust to fonts that have a
unicode-range descriptor that includes a bicameral script. I.e. the
adjustment is not made to unicameral fonts. Those fonts use the
font-size as is.

Here is a summary of my suggested changes:

1. Initial value of font-size-adjust. This should be the aspect value of
the first available font in that element's font-family list. This value
is inherited by child elements.

2. Description of font-size-adjust. Get rid of the "first choice font"
and "substitution font" stuff. Instead just use the ratio of the
inherited aspect and the aspect of the available font(s).

3. font-size spec. Change this to use either ascender or cap-height
(plus descender) for bicameral fonts; nominal height for unicameral
fonts.

Erik

PS If people are worried about changing the definition of font-size from
that used by current implementations, we should choose a definition that
gets us as close as possible to the values used by the browsers' default
fonts. I.e. take a look at ascenders and cap-heights in Times, and see
which one is closest to the em square value used by current
implementations. I.e. we need to take (ascender + descender) OR
(cap-height + descender). Probably NOT (max ascent + max descent).
Received on Saturday, 22 January 2000 19:06:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:03 GMT