1651900 - Layout issue with font-size, line-height and monospace font

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect)

Description

[Jakub T. Jankiewicz]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

The issue can be observed in this CodePen demo https://codepen.io/jcubic/pen/OJMZBmQ

there is ASCII art with underscore and css that included in CSS panel.
css look like this:

font-family: monospace;
line-height: 14px;
font-size: 12px;

and span where text is added have height 15px (it's 14px in Chrome) and container div 14px. So the underscore is cut off. What's weird is that If I use line-height: 1; the issue is fixed but the height of container and span is exactly the same.

Here is the fix https://codepen.io/jcubic/pen/vYLrOBK

This is tested in Firefox 78 on GNU/Linux.

Actual results:

The ASCII art underscores are cut off

Expected results:

ASCII art should look the same as in Google Chrome

Comment 1

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

That codepen uses line-height: 14 rather than line-height: 14px, which is something completely different though, doesn't it?

Comment 3

[Jakub T. Jankiewicz]

It was mistake/typo, I wanted to include relevant CSS directly at CodePen (the library have 14px), and it's the same when there is 14px. Updated the demo.

Comment 4

[Jonathan Kew [:jfkthame]]

The results probably depend on the particular monospace font that's configured. (I do see this issue on my Ubuntu system, where monospace maps to DejaVu Sans Mono, but YMMV.)

Looking at DejaVu Sans Mono, I see that it has inconsistent metrics in the 'hhea' table vs the 'OS/2' table, so the expected results may vary depending which set of metrics the application chooses to use. In 'hhea', it has

ascent = 1901
descent = -483
lineGap = 0

which would give a total line height of 2384 units, on an em-square of 2048 units; so at 12px, line height should compute to 12*2384/2048 = 13.96875px, or just shy of 14px.

But the 'OS/2' table has

ascender = 1556
descender = -492
lineGap = 410

for a total of 2458 units, so at 12px, we'd expect line-height to be about 14.40234375px.

And then there may be effects of pixel-rounding and/or FreeType's fixed-point computations, which IIRC happens individually for the ascent and descent before we see them; this can result in irregularities because the sum of pre-rounded or -quantized values may not match the result we'd get if we added them first and only then rounded or quantized the result.

All of which is to say... this is an area that is kinda fraught with hazards and complications, and is known to be not entirely interoperable. Even if we eliminated the rounding issues, there's still the issue that the results will depend on what particular monospace font is configured on the user's system. Hard-coded assumptions about the height of text are generally pretty fragile.

Comment 5

[Jakub T. Jankiewicz]

@JonathanKew do you know why on same system it works fine in Chrome but not in Firefox? is that Chrome use some tricks or it just use different font?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Font selection varies between browsers, so chances are Chrome is using a different font. The line-height: normal computation also varies between browsers historically.