The &perp; entity breaks text beneath it in a <p> excessively

RESOLVED INVALID

Status

()

RESOLVED INVALID
11 years ago
10 years ago

People

(Reporter: cud, Unassigned)

Tracking

(Depends on: 1 bug, {regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

Summary is sufficient...

Reproducible: Always

Steps to Reproduce:
Retrieve the URL specified above into FF 3 beta 4
Actual Results:  
Notice that, after the line wraps, there is excessive space between the first line that contains &perp; and the ones after

Expected Results:  
Line spacing shouldn't be affected by the entity.

Comment 1

11 years ago
Please set the version from unspecified to 1.8 branch. This bug doesn't exist on the 1.9 branch.
(Reporter)

Comment 2

11 years ago
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre
> Gecko/2008040108 Firefox/3.0pre
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre)
> Gecko/2008040408 Firefox/3.0pre
> 
> Summary is sufficient...
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> Retrieve the URL specified above into FF 3 beta 4
> Actual Results:  
> Notice that, after the line wraps, there is excessive space between the first
> line that contains &perp; and the ones after
> 
> Expected Results:  
> Line spacing shouldn't be affected by the entity.
> 

(Reporter)

Comment 3

11 years ago
Don't know how to change the version.  Had to enter using FF2, due to FF3beta crash.  The corrected info is above.

Comment 4

11 years ago
Helge, to change the version, on the top of your page where it says Version, and had the drop down, select the appropriate version.  Then press Commit at the bottom of the page.

Comment 5

11 years ago
Just to be clear -- this bug exists on trunk (e.g. Firefox 3 Beta 4) but not in Firefox 2.0.0.x, right?
(Reporter)

Comment 6

11 years ago
(In reply to comment #5)
> Just to be clear -- this bug exists on trunk (e.g. Firefox 3 Beta 4) but not in
> Firefox 2.0.0.x, right?
> 
Yep.  Changed to trunk, April 1, 2008, no fool...
Version: unspecified → Trunk
(Reporter)

Comment 7

11 years ago
This doesn't just happen with &perp; or any & entity.  It also happens with insertion of the Unicode &#x21E9; right-pointing hollow (white) arrow.  The excessive space is inserted by the formatter above, as well as after, the such a glyph.

Updated

11 years ago
Component: General → Layout: Fonts and Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text

Updated

11 years ago
Keywords: regression, testcase
(Reporter)

Comment 8

11 years ago
The excessive line spacing between a line that contains an entity reference or Unicode glyph and the preceding and succeeding line does NOT happen if the font-family: in force for the glyph is monospacing (e.g., Courier) — only proportional (e.g., Times).  Still exists in Gecko 1.9 2008041707.
I don't see an issue here with a m-c mac build.  Is this Windows-specific?  Or does it just depend on particular fonts (e.g. not having that Unicode character in the default font you're using and having to fall back to a font with different metrics for it)?
(Reporter)

Comment 10

10 years ago
Boris, the problem still exists in FF 3.0.7's Windows build as of 3/09.  To replicate, browse the simple (narrowed-down) HTML markup pointed to by the URL at the top of this report.  Under Windows, you should see that, when the browser window is sized so that the paragraphs containing the glyphs flow to result in multiple lines, those that have the glyphs render with excessive spacing above and below as compared to those that don't.  If you change  the document's base font (or a paragraph's) to monospacing, however, the excessive line spacing goes away: The error is happening in code that processes (flows) proportional-font text that has these glyphs.
> Boris, the problem still exists in FF 3.0.7's Windows build as of 3/09.

Note that this is code that's over 9 months old at this point...  Hence me ccing someone who might be able to test on a more recent build.

> The error is happening in code that processes (flows) proportional-font text

Or your default monospace font actually has glyphs for these characters, whereas your default proportional font does not.
(Reporter)

Comment 12

10 years ago
3.0.7 is the code that FF gets from the Web off the released build.  I'm not testing with beta code.

Yes, if I set FF to use Lucida Unicode as the default font, the problem goes away, as it also does with other proportional Unicode fonts. The problem is that, if FF can’t find a glyph in the default font, then grabs it elsewhere, its renderer shouldn’t break the default font's line spacing.  The metrics of the font in force should determine the line metrics, not the metrics of the font from which the symbol was somehow fetched by substitution. That seems rather heavy-handed to me.
I'm not asking you to test with beta code.  I'm asking Martijn to do that.  In any case, given the rest of your comment it's not needed.

> if FF can’t find a glyph in the default font, then grabs it elsewhere,
> its renderer shouldn’t break the default font's line spacing.

It has to, to prevent glyphs overlapping.  Other UAs do the same thing, for what it's worth.

> The metrics of the font in force should determine the line metrics

That's not what the CSS spec says.  It in fact says that all the glyphs on the line are used to determine the line metrics.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Note that the likely change from fx2 to fx3 here was which exact font the fallback happened to, by the way...  Fx2 had the same behavior here otherwise.
http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced

"If more than one font is used (this could happen when glyphs are found in different fonts), the height of the content area is not defined by this specification. However, we suggest that the height is chosen such that the content area is just high enough for either (1) the em-boxes, or (2) the maximum ascenders and descenders, of all the fonts in the element. Note that this may be larger than any of the font sizes involved, depending on the baseline alignment of the fonts."

This bug looks like a good example why the maximum ascenders and descenders is a bad choice.  The maximum ascent/descent of the glyphs actually used rather than the highest/lowest glyph in the font used would give better results (but may cost more to calculate).
Depends on: 402473
(In reply to comment #13)
> It has to, to prevent glyphs overlapping.  Other UAs do the same thing, for
> what it's worth.

At least a similar kind of thing.  ISTR IE7 apparently using different (smaller) metrics for Cambria Math though.
You need to log in before you can comment on or make changes to this bug.