Bug 75710 - [Qt] Test fonts metric differencies with Qt5
Summary: [Qt] Test fonts metric differencies with Qt5
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: LayoutTestFailure, Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2012-01-06 09:32 PST by Balazs Kelemen
Modified: 2012-01-10 09:13 PST (History)
5 users (show)

See Also:


Attachments
passing font face (882 bytes, text/plain)
2012-01-06 09:46 PST, Balazs Kelemen
no flags Details
not passing font face (889 bytes, text/plain)
2012-01-06 09:47 PST, Balazs Kelemen
no flags Details
proposed patch for testfonts (374.28 KB, patch)
2012-01-10 07:11 PST, Balazs Kelemen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Balazs Kelemen 2012-01-06 09:32:40 PST
We have a pretty annoying issue that makes tests fail on some systems (like the VM Zoltan set up on Amazon and his own desktop) with Qt5.
The problem is font metrics. Strangely enough on this issue is not triggered on other, seemingly equivalent systems (same Ubuntu version, same system fonts, same fontconfig and freetype version).

An example (css2.1/t1001-abs-pos-cb-02-b-diff.txt). :
-    RenderText {#text} at (0,0) size 260x21
-      text run at (0,0) width 260: "There should be no red on this page."
+    RenderText {#text} at (0,0) size 212x21
+      text run at (0,0) width 212: "There should be no red on this page."
Comment 1 Balazs Kelemen 2012-01-06 09:44:21 PST
Some debugging showed that there is no difference in the font used on the system where the issue is triggering. The same font is used from the testsfonts as it should be, so different system fonts is not a reason for the failures.

The culprit is QFreetypeFace::getFace (qfontengine_ft.cpp)

} else if (FT_New_Face(freetypeData->library, face_id.filename, face_id.index, &face)) {
   return 0;
}

filename and index are the same, the file is n019043l.pfb from the testfonts.
However, freetype gives a different font face with different glyphs and advances.
So it seems to be a change in freetype or something similar.
The question is how could we avoid these differences without rebasing every platform result.
Comment 2 Balazs Kelemen 2012-01-06 09:46:07 PST
Created attachment 121442 [details]
passing font face

This is what freetype gives to us on a system where the tests are passing
Comment 3 Balazs Kelemen 2012-01-06 09:47:41 PST
Created attachment 121443 [details]
not passing font face

... and this is what we get where the tests are failing
Comment 4 Balazs Kelemen 2012-01-09 03:48:06 PST
(In reply to comment #1)
> Some debugging showed that there is no difference in the font used on the system where the issue is triggering. The same font is used from the testsfonts as it should be, so different system fonts is not a reason for the failures.
> 
> The culprit is QFreetypeFace::getFace (qfontengine_ft.cpp)
> 
> } else if (FT_New_Face(freetypeData->library, face_id.filename, face_id.index, &face)) {
>    return 0;
> }
> 
> filename and index are the same, the file is n019043l.pfb from the testfonts.
> However, freetype gives a different font face with different glyphs and advances.
> So it seems to be a change in freetype or something similar.
> The question is how could we avoid these differences without rebasing every platform result.

Sorry, I missed it. The font is different on the two different system. It should use n019003l.pfb but it picks up n019043l.pfb on some systems and that's why it fails. So the difference is the fallback font choice, maybe related to fontconfig.
Comment 5 Balazs Kelemen 2012-01-09 07:14:45 PST
Seems like we can workaround this by simply removing the second font file from testfonts. After that qt will pick up the first everywhere. I am going to check wether any other tests need that. Of course there should be some bug in Qt's font machinery that makes it's behaviour seemingly undetermined across systems but I'm not sure it worth to investigate it further.
Comment 6 Balazs Kelemen 2012-01-09 09:43:34 PST
Well, I have a new "theory". It's the ordering of the result of FcFontList that vary. I'm going to look deeper tomorrow.
Comment 7 Balazs Kelemen 2012-01-10 07:11:15 PST
Created attachment 121842 [details]
proposed patch for testfonts
Comment 8 Balazs Kelemen 2012-01-10 09:13:10 PST
Landed into testfonts.