I can see a red box below the face on today's trunk selfbuilt, ftp downloaded 32bit build from today, from 29th, 20th and 10th. I'm sure that I saw clean acid2 on my builds a few weeks ago, so it's probably related to some environment tools update. It was also reported in bug 365191 comment 1 and 2. Setting LC_ALL=C ./firefox doesn't help.

The red element is img from: <div class="image-height-test"><table><tr><td><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAIAAAFSDNYfAAAAaklEQVR42u3XQQrAIAwAQeP%2F%2F6wf8CJBJTK9lnQ7FpHGaOurt1I34nfH9pMMZAZ8BwMGEvvh%2BBsJCAgICLwIOA8EBAQEBAQEBAQEBK79H5RfIQAAAAAAAAAAAAAAAAAAAAAAAAAAAID%2FABMSqAfj%2FsLmvAAAAABJRU5ErkJggg%3D%3D" alt=""></td></tr></table></div>

what do you get (in the alert) if you load acid2 and then enter: javascript:void(alert(document.getElementsByTagName("table")[1].parentNode.scrollTop)) into the URL bar? I see the bug if I set scrollTop to 200, but it defaults to 0. (If I poke at the image in DOM inspector, it also scrolls the image into view.)

document.getElementsByTagName("table")[1].parentNode.scrollTop=0 Actually, I *don't* see it after javascript:document.getElementsByTagName("table")[1].parentNode.scrollTop=200 ;)

What do you see on this testcase? (I see the expected results described, but I expect you don't.)

that's how it looks here

A guess is that you might be getting a bitmap font that only goes up to a certain size.

How about this one?

Fx trunk and Konqueror 3.5.5

The testcase specifies the generic family name, so, the testcase depends on your Fx prefs. What specify in the prefs? If the prefs are actual font name, I don't have the idea for this bug. If the prefs are alias name of the system (e.g., "serif", "sans"...), that is a system settings...

This may be able to fix this bug, but I cannot test it.

Sorry, this is better.

Not a linux-only bug, see bug 365191 comment 1.

Let me also repeat that the test passes here from time to time, e.g. when fully loaded in a background tab. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070102 Minefield/3.0a2pre ID:2007010204 [cairo]

This bug is about problems on X11-based GTK-based platforms. File separate bugs for other platforms.

Comment on attachment 250209 [details] [diff] [review] proposal patch #1.0000000001 This patch fixes the bug for me. I can confirm that both testcases looks like in Konq now, and that Acid2 test works perfect with this patch.

this effects just the list of substitute fonts, right?

(In reply to comment #16) > this effects just the list of substitute fonts, right? > right. I'll attach the formal patch.

I think that we should unify the common parts for fontconfig for BeOS/GTK2. I'll file the bug after this...

(In reply to comment #14) > This bug is about problems on X11-based GTK-based platforms. File separate > bugs for other platforms. -> bug 365809

I don't understand -- the patch would fix the problem, but doesn't it mean that it won't be possible to use bitmap fonts at all? Aren't there some fonts that are only bitmap for some languages?

This patch stops to support for bitmap font that doesn't have vector data for non-bitmapped size. By the patch, the bitmap only fonts are same as non existing font on Gecko, because they cannot be found by fontconfig with the limitation.

oh, sorry, I didn't understand what you wanted to say. You are right, the patch may not be able to render the some scripts if that is only rendered by the non scalable bitmap fonts. I think that this issue is not good thing for intl, but the non scalable font is breaking the layout of css...

Is this still an issue now that GTK1/Xlib is going away?

I believe this was filed as a cairo build, so yes.

Does this appear in cairo-gtk2 as well? Or isn't cairo-gtk going away after all?

cairo-gtk1 never existed

Sorry, I'm not truly into linux toolkits, I'm mainly win&mac.

Comment on attachment 250324 [details] [diff] [review] Patch rv1.0 I have an idea. We use bitmap font only when the font family is specified directly (i.e., the font is not resolved from generic family names).

I used to see this and now I don't. We just changed the default fonts, right?

(In reply to comment #29) > I used to see this and now I don't. We just changed the default fonts, right? Yes, the default fonts have been changed to use system defaults. See bug 359777. (Preferring scalable fonts when no specific bitmap font is specified may still be a good idea, though.)

(In reply to comment #30) > (Preferring scalable fonts when no specific bitmap font is specified may still > be a good idea, though.) Actually fontconfig should be doing that already. If the size is not matched, then fontconfig should be preferring scalable fonts unless only a bitmap font matches a family specified either in the page or in Mozilla prefs or in fontconfig aliases. So, I'd expect this bug to be WFM unless Mozilla prefs or fontconfig configurations prefer families with only bitmap fonts. If preferences specify bitmap fonts then we should use bitmap fonts (if they match the size within a 20% tolerance).

I'm resetting bugs which are assigned to me but I'm not working on them and I don't have plan for fixing them in near future.

I'm not seeing this behavior any longer with any of the test cases, but if it is still an issue, please reopen.