Re: font-size and accents, again

On Mon, 22 Nov 1999 11:44:36 -0800, Todd Fahrner (fahrner@pobox.com)
wrote:
> I agree with you (and Erik) that CSS could be more explicit here. I 
> think your reading of CSS, as far as it goes, is tenable. However, 
> your reading (and tests) do not match the definition of font-size as 
> understood by digital font designers, and as respected by all 
> (digital) font rendering systems I've ever heard of.

I'd have to disagree with that.  In the Windows API, it's trivial to
ask for sizing either way.  The patch needed to make Mozilla pass my
test [1] on Windows is a one character change:  the removal of a "-"
sign.  This is because (in the Windows API for describing a font [2]) a
positive value for lfHeight (the font height requested) is interpreted
as a size that contains all the characters in the font (the "cell
height", which is the height [3], or "my way") but a negative value is
interpreted as (the negative of) the desired ascent + descent (the
"character height", which is the height minus the internal leading [3],
or "your way") [2].  Browsers have traditionally chosen the latter.

> Thought experiment: imagine a "dingbat" font - one consisting 
> entirely of pictographs and symbols. In Dingbatiana, there are no 
> ascenders or descenders in the roman character sense. Suppose, in 
> fact, that all of these symbols fit neatly in the ex-height area of a 
> font like Times New Roman - by design. The font designer intends that 
> these symbols sit on the baseline and blend unobtrusively with Times, 
> at whatever size. In order for this to work, should the typesetter 
> need to use, say, 18pt Times and 8.5pt Dinbatiana? Or should s/he use 
> 18pt of both? It's the latter, most assuredly.

I don't think there's anything wrong with a font being smaller that its
bounding box - only bigger.  (I'm not sure how the Windows API
mentioned above handles this case, though.)

> >Also, I'd like to clarify one point about my article on font sizes
> >[3].  Although I would like to see font-sizes supported according to
> >the spec (since this makes authors' suggestions more portable, as Erik
> >mentioned in [4]), I think it's more important that there be a
> >consistent solution.  One of the main points I wanted to make is that,
> >if we accept that font-size does *not* refer to the outermost extent of
> >the glyphs, then user agents should be consistent in their treatment of
> >line-height, backgrounds, and 'em' units.
> 
> No disputes here.
> 
> >I would propose the following solution for handling fonts that are
> >bigger than they claim to be: the 'em' unit should be the actual value
> >of the font-size as stated by the font, but scaling factor units for
> >line-height and the height used for backgrounds (and padding and
> >border) on inline elements should be based on the "true" font-size
> >(including all the height of the glyphs).
> 
> Not quite sure what you mean by "scaling factor units for line-height 
> as stated by the font". Can you provide a case illustrating the 
> difference between the two approaches?

I don't see those exact words you quote.  However, consider the
following style rules:

p.one {
  font-size: 20px;
  line-height: 1.2;
  }

p.two {
  font-size: 20px;
  line-height: 1.2em;
  }

span {
  background: green;
  color: yellow;
  border: 1px solid red;
  }

img {
  height: 1em;
  vertical-align: bottom;
  }

applied to the following markup:

<p class="one">
  Some text with a <span>span</span> and an <img src="image" alt="image">
  in it.
</p>

(and the same for a p element with class="two")

Suppose that the font used for the "p" element has a height minus
internal leading of 20px (as requested) but its height (including the
internal leading) is 24px (see [3] for the Windows API documentation on
this.  My understanding (based on Mozilla bug 13072) is that requesting
a font by positive lfHeight [2] corresponds to the tmHeight [3], but
requesting based on a negative lfHeight (as all current browsers do)
corresponds to (tmHeight - tmInternalLeading) [3].

The existing difference between the line-height values in the two
paragraphs is that the factor of 1.2 inherits as a factor, and so is
applied as a factor of 1.2 to text with a different font-size, but the
line-height of 1.2em inherits by its computed value, 24px, and thus
has the potential to cause strange results.

There is a strong expectation that 1em should be equivalent to the
requested font-size.  That is, in this case, 1em should be 20px,
so the image should be 20px tall.  That is part of my proposal.

To be consistent with this proposal, a line-height of 1.2em should be a
line-height of 24px.  This means there should be no external leading
added to the font.  (I have not tested this part of the proposal with
any current implementations.)

However, the most important bit is that I am proposing that if we
continue to use the fonts with 24px height, then the line-height in the
first paragraph (which is the height of every line box) should be
28.8px (1.2*24px), which is different from the 24px line-height in the
second paragraph.  This is the current behavior of Mozilla and MacIE
4.5, is sometimes the behavior of WinIE5, and is not the behavior of
Opera (see the table in [1]).

Furthermore, I am proposing that the background of the span element be
24px tall in both cases, and that the border go around that 24px.  This
is the behavior of all implementations that choose one option or the
other except for Opera.

The biggest problem with Opera's solution is that fonts do not seem to
contain information (or at least the Windows API [3] does not expose
it) about *where* the internal leading lies (i.e., whether it's at the
top or the bottom).  This creates the problems with backgrounds and
borders (and also the positioning of the text relative to its
containing block) that are seen in [4].  Note that the colored
backgrounds on the letter "x" do not extend low enough to cover the
descenders of letters like "p" or characters like "[" since the
internal leading in this font is (largely) at the top, but Opera
assumes it is at the bottom.  (Even if the font did indicate where the
internal leading lies, the backgrounds would still be ugly for letters
with diacritical marks.)

> >  > [1] "The font size refers to the size of the font from baseline to
> >  > baseline, when set solid (in CSS terms, this is when the 'font-size'
> >  > and 'line-height' properties have the same value)."
> >
> >  (where did you get this quote?)
> 
> CSS-2 on font-size: http://www.w3.org/TR/REC-CSS2/fonts.html#font-properties.

What's missing is what "set solid" means in terms other than CSS terms.

Note that if it weren't for backwards compatibility I would be arguing
strongly for using the different definition of font-size (including the
internal leading), since it would avoid all these problems.

-David

[1] http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/
[2] http://msdn.microsoft.com/library/psdk/gdi/fontext_1wmq.htm
[3] http://msdn.microsoft.com/library/psdk/gdi/fontext_2zqq.htm
[4] http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/opera

L. David Baron    Sophomore, Harvard (Physics)    dbaron@fas.harvard.edu
Links, SatPix, CSS, etc.     <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                      <URL: http://www.webstandards.org/css/ >

Received on Monday, 22 November 1999 16:37:32 UTC