Closed Bug 4234 Opened 23 years ago Closed 23 years ago

{css1} font-size not interpreted correctly

Categories

(Core :: Layout, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED DUPLICATE of bug 13072

People

(Reporter: dbaron, Assigned: peterl-retired)

References

()

Details

(Keywords: css1)

I think you are not quite interpreting font-size correctly on Windows 95.  You
should have access to exact fonts, so the inlinetest should pass.  Everything's
a little off.  It looks to me that what you are doing for, say, a 22px font, is
getting the font that Windows calls 22px, and then finding its real height
(say, 24px), and using that (as you should) in later calculations.  However, I
think you should be using the font that is really 22px (from highest glyph top
to lowest glyph bottom).

I think erik@netscape.com may have been working on this, judging by his posts:
http://lists.w3.org/Archives/Public/www-style/1999Mar/0096.html
http://lists.w3.org/Archives/Public/www-style/1999Mar/0105.html

This problem also shows up in the test

http://www.fas.harvard.edu/~dbaron/csstest/linebox4

where the yellow stripes are slightly too thick.
Whatever you do, don't cause a regression in:

http://www.webstandards.org/css/opera/lineheightdemo1.html

which is currently correct.
Status: NEW → ASSIGNED
Some more data from dbaron:

I set GECKO_USE_COMPUTED_HEIGHT=1 and the inlinetest is still a little
bit off (not as much).  Image at:

http://www.fas.harvard.edu/~dbaron/misc/it_uch.gif

On another note, the computed height changes seem to occur on everything,
and always biased the same way:

240 instead of 285 (Times)
360,390 (Times)
200,240 (Times)
216,240 (Verdana)
240,270 (the font in http://www.fas/~dbaron/csstest/ )
204,225 (FONT element in http://www.mozilla.org/ )

This is what I was saying about funny stuff on Windows - it could be useful
for debugging 4234.
The following test case also shows problems (if my memory is correct, since I'm
don't have a build right now):

http://www.fas.harvard.edu/~dbaron/csstest/emunit
Note that the problem to which David is referring is (presumably) not the
inheritance issue (see bug 3116, fixed today) but the sizing bug.

The page contains squirrel images sized to height:1em, within text which has a
background specified.

The problem is that the cute squirrels are not sizing to fit the whole the
height of what is 1em, the font-size, but are only becoming the height of
a letter "M" (approximately, anyway). See the explanation at the very top
of the document.

Quick example:
   if SPAN { font-size: 50px; background: yellow; padding: 0; }
  and IMG  { height: 1em; }
 then the height of an image in the SPAN should be exactly 50px, and the
      background of the SPAN should be exactly 50px high too.
See a piece I'm writing at:

http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/
Summary: font-size not interpreted correctly → {css1} font-size not interpreted correctly
QA Contact: 4144 → 4110
The problem is that when NGLayout is asking for a font of, say, 10px, the OS is
using a different definition of font-size than the OS' definition to actually
draw the text.

In CSS, the font-size is the distance from the top of the tallest glyph of a
font to the bottom of the lowest glyph of a font.

In most OS, the font-size appears to be measureed excluding diacriticals.

To get around this problem, NGLayout should find what the distance between
the top of the tallest glpyh of the font to the bottom of the lowest glyph of
the font is (call this value 'c'), in the font's internal units, and then find
out what the font *thinks* its font-size is (call this value 'f'), also in the
font's units.

Then, when NGLayout requests a font of size 'x', it should actually request
a font of size x*c/f. This would thus translate between the CSS and OS
definitions of font-size in a simple, XP manner.

The only difficult bit in all this is trying to find 'c' and 'f'. The value 'f'
can probably be found easily by querying the OS (this is not XP, unfortunately)
for data about the font. Finding 'c' may be more difficult. Possibly, it could
be found by querying for the actual height of every glyph in the font. This is
obviously not very efficient. Some font experts should be able to help here.
Oops! That formula is wrong. I meant:

   CSS-font-size * f/c = OS-font-size

So, to get a font of font-size "x" in CSS terms from the OS, you request a font
of size x*f/c from the OS.
This page:
   http://outlook.microsoft.com/typography/OTSPEC/recom.htm
...may be useful. In particular, the "Baseline to Baseline Distances" section.
It is part of the the Microsoft Typography section on TrueType fonts:
   http://outlook.microsoft.com/typography/tt/tt.htm
Most documents on that site are in Word format, so I have not examined them.

There is a FAQ on fonts:
   http://www.nwalsh.com/comp.fonts/FAQ/index.html
However, this document seems to only address the issues pertinent to users, not
application programmers.
Actually, ignore those last three comments. I think that is what you are already
doing. That is what is wrong.

Lets start again.

The test cases to look at are:

   http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/
   http://www.fas.harvard.edu/~dbaron/css/test/inlinetest
   http://www.fas.harvard.edu/~dbaron/css/test/linebox4
   http://www.fas.harvard.edu/~dbaron/css/test/emunit

Assuming fully scalable fonts are available, as they are on Windows: When
drawing a font with font-size 'x'px, you should ask the OS for a font of with
a size of 'x'px. The background should have a height of exactly 'x'px. Anything
with a size of 1em should have a size of exactly 'x'px.

Quick example:
   if SPAN { font-size: 50px; background: yellow; padding: 0; border: none; }
  and IMG  { height: 1em; }
 then the height of an image in the SPAN should be *exactly* 50px, and the
      background of the SPAN should be *exactly* 50px high too. Any text in
      the SPAN should have a nominal height of 50px, but this DOES NOT mean
      that the distance between the bottom of the lowest glyph to the top of
      the highest glyph will necessarily be exactly 50px, it may be a
      considerably bigger or smaller value. *This means glyphs may well spill
      out from the background*. [1]

The actual fonts may quite possibly spill into surrounding boxes, lines, text,
and so forth (assuming 'overflow' is set to 'visible', anyway).

An example of probably correct rendering of the first case listed above,
   http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/
...is Opera's rendering of the page:
   http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/opera
...(at least, assuming it is using the correct font-size).

Hopefully, we may soon have a specially designed font to examine these issues
with more accuracy. If we do, then we will be able to generate much more
accurate tests. Stay tuned.

([1] To prevent glyphs from spilling out of the background, a web designer would
 use the padding properties. To prevent glyphs from flowing into surrounding
 _lines_, the web designer would use the 'line-height' property. This is not
 important for solving this bug.)
Some more accurate test pages are now available:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight3.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight4.html

These test pages use a font called Ahem, designed by Todd Fahrner. Instructions
for downloading the font are included on the test pages themselves. The font
must be installed before passing a browser through the tests.

Mozilla passes lineheight3 without any problems. All the problems are on the
lineheight4 page. It appears that you are using the _actual_ size of the font
rather than the size of the font that you asked for, when doing calculations
with the font size (e.g., for drawing the bg behind the font).
Assignee: kipp → peterl
Status: ASSIGNED → NEW
Hey peter - can you argue with david about how we should be interpret font-size
in gecko, and once you have a resolution either kill the bug or reassign it to
the right person to handle the fix?

thanks...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
This bug has become so confused (largely due to some misunderstandings that
I had about the whole issue) that I have broken out a new bug. This bug is
therefore now a duplicate of bug 13072.

*** This bug has been marked as a duplicate of 13072 ***
Status: RESOLVED → VERIFIED
Verified dup of #13072
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
You need to log in before you can comment on or make changes to this bug.