User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20080311 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20080311 Firefox/126.96.36.199 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 ⊥ and the ones after Expected Results: Line spacing shouldn't be affected by the entity.
Please set the version from unspecified to 1.8 branch. This bug doesn't exist on the 1.9 branch.
(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 ⊥ and the ones after > > Expected Results: > Line spacing shouldn't be affected by the entity. >
Don't know how to change the version. Had to enter using FF2, due to FF3beta crash. The corrected info is above.
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.
Just to be clear -- this bug exists on trunk (e.g. Firefox 3 Beta 4) but not in Firefox 2.0.0.x, right?
(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
This doesn't just happen with ⊥ or any & entity. It also happens with insertion of the Unicode ⇩ right-pointing hollow (white) arrow. The excessive space is inserted by the formatter above, as well as after, the such a glyph.
Component: General → Layout: Fonts and Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
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)?
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.
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.