Closed Bug 365680 Opened 18 years ago Closed 13 years ago

[GTK] Acid 2 is broken because we pick bitmap fonts

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: zbraniecki, Unassigned)

References

(
URL
)

Details

Attachments

(6 files, 2 obsolete files)

screenshot
18.59 KB, image/png
Details
possible testcase
881 bytes, text/html; charset=UTF-8
Details
screenshot of the testcase
11.46 KB, image/png
Details
possible testcase #2
284 bytes, text/html; charset=UTF-8
Details
screenshot of testcase2
43.51 KB, image/png
Details
Patch rv1.0
4.32 KB, patch
Details | Diff | Splinter Review
Attached image screenshot — 
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
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

;)
Component: Layout: Block and Inline → Layout: Tables
Attached file possible testcase — 
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.
Attached image screenshot of testcase2 — 
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...
Attached patch proposal patch #1 (obsolete) — — Splinter Review 
This may be able to fix this bug, but I cannot test it.
Attached patch proposal patch #1.0000000001 (obsolete) — — Splinter Review 
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.
Attached patch Patch rv1.0 — — Splinter Review 
I think that we should unify the common parts for fontconfig for BeOS/GTK2. I'll file the bug after this...
Assignee: nobody → masayuki
Attachment #250209 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #250324 - Flags: review?(vladimir)
(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?
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).
Attachment #250324 - Flags: review?(vladimir)
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
Status: ASSIGNED → NEW
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: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: