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

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
11 years ago
6 years ago

People

(Reporter: gandalf, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments, 2 obsolete attachments)

(Reporter)

Description

11 years ago
Created attachment 250184 [details]
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.
(Reporter)

Comment 1

11 years ago
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.)
(Reporter)

Comment 3

11 years ago
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
Created attachment 250190 [details]
possible testcase

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

Comment 5

11 years ago
Created attachment 250191 [details]
screenshot of the testcase

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.
Created attachment 250192 [details]
possible testcase #2

How about this one?
(Reporter)

Comment 8

11 years ago
Created attachment 250193 [details]
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...
Created attachment 250208 [details] [diff] [review]
proposal patch #1

This may be able to fix this bug, but I cannot test it.
Created attachment 250209 [details] [diff] [review]
proposal patch #1.0000000001

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
(Reporter)

Comment 15

11 years ago
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

Comment 16

11 years ago
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.
Created attachment 250324 [details] [diff] [review]
Patch rv1.0

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...

Comment 23

10 years ago
Is this still an issue now that GTK1/Xlib is going away?
I believe this was filed as a cairo build, so yes.

Comment 25

10 years ago
Does this appear in cairo-gtk2 as well? Or isn't cairo-gtk going away after all?
cairo-gtk1 never existed

Comment 27

10 years ago
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)

Comment 29

10 years ago
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
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.