Re: font-size and accents, again

At 1:36 PM -0500 11/22/99, L. David Baron wrote:
>On Fri, 19 Nov 1999 10:10:07 -0800, Todd Fahrner (fahrner@pobox.com)
>wrote:
>  >
>  > At 8:57 AM -0800 11/19/99, Erik van der Poel wrote:
>  >
>  > >Just to confirm, when you say "when set solid", you mean making the
>  > >distance from baseline to baseline equal to the em, right?
>  >
>  > Yes. CSS-2's definition of font-size [1] uses this semi-circular
>  > language: font size is the size the font says it is.
>
>This is where I disagree.  I think this is because I picked up a
>non-CSS definition of set solid from Roland Eriksson (I can't find a
>reference - it may have been through email discussion - please correct
>me if I'm wrong): the term "set solid" originates from typesetting in
>metal, where pieces of brass were used to create leading [2].  If no
>such metal were used, then the text is "set solid."  Since the
>characters on the glyphs can't extend past the rectangles that those
>characters are on, glyphs in adjacent lines can't overlap

Right. This restriction does not exist in digital font formats such 
as Type 1 and TrueType/OpenType. Reasoning from lead and brass, I 
submit, is useful only to a certain degree - to understand origins. 
Letterpress printing does not define the state of the art.

>when set
>solid, but they can touch.  Since CSS makes no further attempt to
>define "set solid," and defining it in terms of line-height and
>font-size would be circular, this is the only adequate definition I
>know.

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.

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.

>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 am confused about many inline box-model issues; my failure to see 
your point is probably related. Until I get clear, I don't have an 
opinion about your proposal here.

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

--
Todd Fahrner

Received on Monday, 22 November 1999 14:44:54 UTC