182738 - line-height in preformatted text should not be changed by characters from another font

Status: NEW

(Core :: Layout: Block and Inline, defect, P4)

Description

[Alexey Chernyak]

OS: Win2K
Build: 2002111904 (Trunk)

At the bottom of UTF-8 example in provided URL are box drawing alignment tests.
They become broken, because line-height increases when missing characters get
picked from another fonts.

If a fixed line-height is applied to the same preformatted text, the problem
gets fixed.

This is probably related to bug 159374.

Comment 1

[Alexey Chernyak]

Attachment: testcase

Comment 2

[Alexey Chernyak]

Attachment: plain text testcase

Comment 3

[Hixie (not reading bugmail)]

What glyph is picked shouldn't affect the computed value of line-height that is
used to size the lines... does the problem not still occur if there are only
characters from the one font? A testcase with only the first box (because I have
fonts missing from the other bits too) would be cool.

If indeed that makes a difference, then this sounds like a valid bug to me.

Comment 4

[Alexey Chernyak]

That is exactly what's happening. When all characters are from the same font -
then there is no problem. But if characters get picked from other fonts - then
the line-height increases and vertical box borders get gaps in them.

This is a problem for preformatted text, but I believe this is also happening
for normal text as well (bug 159374).

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This is correct behavior according to my proposal in
http://www.people.fas.harvard.edu/~dbaron/css/2000/01/dibm .  Is there something
in CSS3 contradicting that?

Comment 6

[Alexey Chernyak]

Attachment: reduced testcase

Hopefully your monospace font should have all characters needed to display the
second set of boxes and miss characters from the first set.
The first testcase was created for version 2.82 of Courier New font.

Comment 7

[Alexey Chernyak]

At the bottom of Section 3.4 of CSS3 Line module draft
http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#InlineBoxHeight
it says:

"When an element contains text that is rendered in more than one font, user
agents should determine the 'line-height' value according to the largest font
size (when appropriate)."

This is clearly inappropriate for preformatted text in above testcases.

Further it says:

"When the 'line-height' value is less than the font size, the final inline box
extended block progression dimension will be less than the font size and the
rendered glyphs will "bleed" outside the box. If such a box touches the edge of
a line box, the rendered glyphs will also "bleed" into the adjacent line box."

I think this is the behaviour that <pre> (and text/plain) should have in above
testcases.

CSS3 spec obviously doesn't worry much about this issue. :o/

What if majority (or ALL) characters are taken from another font?

I think it is simply important to be consistent in preformatted text, and it
wouldn't matter much for which font line-height is picked, as long as it doesn't
differ from line to line.

And chosing which line-height to use for best presentation is probably another
issue.

With HTML it is easier because we can style <pre> to force line-height that we
want. But with text/plain the author has less control over how it is displayed.
However in both cases consistency is assumed, and that's what we should aim at
achieving.

Comment 8

[Hixie (not reading bugmail)]

I don't understand any theoretical way in which the line-height could be
affected by the selected font. To start with, you need a computed line-height
before you even have any text.

The dibm suggests the selected font can affect the size of the _font box_, but
not the line-height, as far as I can tell.


(Note that the testcase renders identically for me both when only one font
matches and when several fonts match. So for me on Windows 2000 this works as I
expect...)

Comment 9

[Alexey Chernyak]

Attachment: screenshot

This is what I see.

Comment 10

[Hixie (not reading bugmail)]

Yeah, that seems wrong.

Note that unless the line-height is '1', '1em', or '100%', or unless the glyphs
in the font bleed, I'd expect there to be a gap between the lines. (If
line-height is set to 'normal', the default, then I'd expect a gap.)

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

> The dibm suggests the selected font can affect the size of the _font box_, but
> not the line-height, as far as I can tell.

However, the font boxes for different fonts could have the baselines at
different positions relative to the font box + leading.

Comment 12

[Alexey Chernyak]

by the way the font that gets picked to replace missing characters in default
monospace font (Courier New v2.82) and causes line height to change is Arial
Unicode MS v1.0

Comment 13

[Alexey Chernyak]

You can get Arial Unicode MS v1.0 as part of Office XP

Comment 14

[Jungshik Shin]

Code2000 by James Kass(http://home.att.com/~jameskass) has almost as extensive a
chracter repertoire as Arial MS unicode and can be used to reproduce what's
reported here. BTW, bug 105026 is related, but I don't think this bug blocks it
because it's more about the horizontal alignment(that depends a lot on the font
availability and the font choice) than about line-height.

Comment 15

[Hans de Goede]

I'm seeing this in Linux too, so the OS part of this bug is not correct, it is
appearantly more generic.

In order to see:
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

Rendered at least partly aligned, you need to select MiscFixed as font instead
of Monospace. Actually I'm seeing lots of problems with Monospace and I believe
monospace should not be the default monospace font. But maybe that should be in
a new bug. All in all I'm seeing 3 problems with the above url in mozilla 1.7 on
Fedora Core 3 (test release):
-The above page (and others) render completly wrong when using the Monospace
font, MiscFixed does a much better job, I believe this should be the default
under Linux, should I report this as a seperate bug?
-With MiscFixed there are blank spaces between the real lines,
 this shows up in the box drawing test, but can also be seen when selecting text
 (the same as this bug, but then under Linux)
-The vertical alignment of the thai verb goes wrong, and so does the spelling
 of stargate, appearantly mozilla doesn't support combining unicode chars,
 this I believe is the cause for bug 105026