Re: font-size and accents, again

"L. David Baron" wrote:
> 
> 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.

This seems to argue that the spec should also choose the latter.

Also, the negative lfHeight thing in Windows is pretty strange, right?
They probably started with positive lfHeights that meant the bounding
box, and then, when they discovered that digital font designers prefer
to use the em square for sizing, they had to come up with some way to
accommodate the font designers and still remain compatible with old
apps. So they came up with the hack of using negative lfHeight to mean
the (negative of) the em square height. Would any Windows people like to
confirm my speculation?

> 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.

If the spec says that a line-height of 1.2em inherits by its computed
value, then perhaps the spec should be changed.

> 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]).

How can you know what the current behavior of the 2nd paragraph is when
you said above that you haven't tested that? (I suppose you were
referring to the current behavior of the 1st paragraph.)

Choosing to use 28.8px (1.2*24px) is wrong, because the font size isn't
24px. That's the bounding box size. The em square is 20px, so the
line-height should be 1.2*20px = 24px.

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

Please, let's get rid of the term "set solid" in the CSS spec(s). It
reeks of the old metal type. It is not at all representative of the new
digital font world.

Erik

> [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

Received on Friday, 3 December 1999 16:56:07 UTC