Closed Bug 365680 Opened 13 years ago Closed 8 years ago
[GTK] Acid 2 is broken because we pick bitmap fonts
18.59 KB, image/png
881 bytes, text/html; charset=UTF-8
11.46 KB, image/png
284 bytes, text/html; charset=UTF-8
43.51 KB, image/png
4.32 KB, patch
|Details | Diff | Splinter Review|
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>
Component: Layout: Tables → Layout: Block and Inline
QA Contact: layout.tables → layout.block-and-inline
Component: Layout: Block and Inline → Layout: Tables
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
Component: Layout: Tables → GFX: Thebes
QA Contact: layout.block-and-inline → thebes
Summary: Acid 2 is broken on some linux boxes → Acid 2 is broken on some linux boxes because we pick bitmap fonts
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.
Attachment #250208 - Attachment is obsolete: true
Not a linux-only bug, see bug 365191 comment 1.
OS: Linux → All
Summary: Acid 2 is broken on some linux boxes because we pick bitmap fonts → Acid 2 is broken because we pick bitmap fonts
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.
OS: All → Linux
Summary: Acid 2 is broken because we pick bitmap fonts → [Linux] Acid 2 is broken because we pick bitmap fonts
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.
Summary: [Linux] Acid 2 is broken because we pick bitmap fonts → [GTK] Acid 2 is broken because we pick bitmap fonts
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.)
Depends on: 359777
(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.
Assignee: masayuki → nobody
I'm not seeing this behavior any longer with any of the test cases, but if it is still an issue, please reopen.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.