Bug 140290 – [GTK] Pixelated fonts used for Engadget headline

• Component: WebCore Misc.
• Status: RESOLVED DUPLICATE

[Xabier Rodríguez Calvar]

Created attachment 244337 [details]
Rendered fonts in Epiphany

I don't know why but some fonts are rendered awefully in WebKitGTK+. You can find a screenshot attached.

[Xabier Rodríguez Calvar]

Created attachment 244338 [details]
Rendered in Chromium

[Martin Robinson]

There are some pieces of information that would be extremely useful in fixing this bug. 

1. Can you use the web inspector to figure out what fonts the CSS is requesting for this text? The CSS rule should be enough.
2. Can you make a HTML page with only that font in it. Upload the reduced test case to this bug.
3. While reproducing the test case, upload the console output when the environment variable FC_DEBUG=2.

I would really like to fix this.

[Carlos Alberto Lopez Perez]

I think this is either because of the fonts or because of some library that we ship on the JHBuild.

WebKit $ WebKitBuild/Release/bin/MiniBrowser http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/
# Horrible fonts.

WebKit $ mv WebKitBuild/DependenciesGTK/ WebKitBuild/DependenciesGTK-back
WebKit $ WebKitBuild/Release/bin/MiniBrowser http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/
# Ok fonts.

[Martin Robinson]

(In reply to comment #3)
> I think this is either because of the fonts or because of some library that
> we ship on the JHBuild.
> 
> WebKit $ WebKitBuild/Release/bin/MiniBrowser
> http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/
> # Horrible fonts.
> 
> WebKit $ mv WebKitBuild/DependenciesGTK/ WebKitBuild/DependenciesGTK-back
> WebKit $ WebKitBuild/Release/bin/MiniBrowser
> http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/
> # Ok fonts.

The availability of fonts can definitely change what font is selected, but we should probably not be selecting a font that doesn't scale properly.

[Carlos Alberto Lopez Perez]

(In reply to comment #4)
> The availability of fonts can definitely change what font is selected, but
> we should probably not be selecting a font that doesn't scale properly.

Seems this is not caused by the fonts, but by the libfont library that we ship.

If I instruct the minibrowser to load the system libfont library instead of the jhbuild one, the rendered text looks ok.

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libfontconfig.so.1 Tools/jhbuild/jhbuild-wrapper --gtk run WebKitBuild/Release/bin/MiniBrowser http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/

[Carlos Alberto Lopez Perez]

(In reply to comment #5)
> (In reply to comment #4)
> > The availability of fonts can definitely change what font is selected, but
> > we should probably not be selecting a font that doesn't scale properly.
> 
> Seems this is not caused by the fonts, but by the libfont library that we
> ship.
> 
> If I instruct the minibrowser to load the system libfont library instead of
> the jhbuild one, the rendered text looks ok.
> 
> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libfontconfig.so.1
> Tools/jhbuild/jhbuild-wrapper --gtk run WebKitBuild/Release/bin/MiniBrowser
> http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/

With "libfont", I actually mean fontconfig.

[Martin Robinson]

(In reply to comment #6)

> With "libfont", I actually mean fontconfig.

Can you determine the exact font that is selected that is causing the pixelation? No matter what fontconfig library is available, we should not be selecting fonts that do not scale properly. Using FC_DEBUG, as I described earlier, should show this.

[Carlos Alberto Lopez Perez]

(In reply to comment #7)
> (In reply to comment #6)
> 
> > With "libfont", I actually mean fontconfig.
> 
> Can you determine the exact font that is selected that is causing the
> pixelation? No matter what fontconfig library is available, we should not be
> selecting fonts that do not scale properly. Using FC_DEBUG, as I described
> earlier, should show this.

I'm not familiar with fontconfig. I'm not able to see nothing relevant on those big log files.

So maybe you can check if you can see something relevant. I have uploaded the output of running the MiniBrowser on http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/ preloading my system fontconfig libraries or without doing that. With both FC_DEBUG=1 and FC_DEBUG=2.

I have uploaded it here: http://people.igalia.com/clopez/wkbug/140290/ (warning: the debug2 files decompress to ~400-800M)

I also tried to run fc-match to see if a different font was selected on each case, and at first sight looks is the same.

$ Tools/jhbuild/jhbuild-wrapper --gtk run fc-match "Segoe UI, proxima-nova, proxima-nova-1, proxima-nova-2, Proxima Nova, Helvetica, Arial, sans-serif"
DejaVuSans.ttf: "DejaVu Sans" "Book"

$ fc-match "Segoe UI, proxima-nova, proxima-nova-1, proxima-nova-2, Proxima Nova, Helvetica, Arial, sans-serif"
DejaVuSans.ttf: "DejaVu Sans" "Book"

[Martin Robinson]

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > 
> > > With "libfont", I actually mean fontconfig.
> > 
> > Can you determine the exact font that is selected that is causing the
> > pixelation? No matter what fontconfig library is available, we should not be
> > selecting fonts that do not scale properly. Using FC_DEBUG, as I described
> > earlier, should show this.
> 
> I'm not familiar with fontconfig. I'm not able to see nothing relevant on
> those big log files.
> 
> So maybe you can check if you can see something relevant. I have uploaded
> the output of running the MiniBrowser on
> http://www.engadget.com/2015/01/04/lenovo-thinkpad-x1-carbon-2015/
> preloading my system fontconfig libraries or without doing that. With both
> FC_DEBUG=1 and FC_DEBUG=2.
> 
> I have uploaded it here: http://people.igalia.com/clopez/wkbug/140290/
> (warning: the debug2 files decompress to ~400-800M)
> 
> I also tried to run fc-match to see if a different font was selected on each
> case, and at first sight looks is the same.
> 
> $ Tools/jhbuild/jhbuild-wrapper --gtk run fc-match "Segoe UI, proxima-nova,
> proxima-nova-1, proxima-nova-2, Proxima Nova, Helvetica, Arial, sans-serif"
> DejaVuSans.ttf: "DejaVu Sans" "Book"
> 
> $ fc-match "Segoe UI, proxima-nova, proxima-nova-1, proxima-nova-2, Proxima
> Nova, Helvetica, Arial, sans-serif"
> DejaVuSans.ttf: "DejaVu Sans" "Book"

It might be best to make a small reproducible test case first. Basically an HTML file with just the headline.

[Martin Robinson]

(In reply to comment #9)

> > $ Tools/jhbuild/jhbuild-wrapper --gtk run fc-match "Segoe UI, proxima-nova,
> > proxima-nova-1, proxima-nova-2, Proxima Nova, Helvetica, Arial, sans-serif"
> > DejaVuSans.ttf: "DejaVu Sans" "Book"
> > 
> > $ fc-match "Segoe UI, proxima-nova, proxima-nova-1, proxima-nova-2, Proxima
> > Nova, Helvetica, Arial, sans-serif"
> > DejaVuSans.ttf: "DejaVu Sans" "Book"
> 
> It might be best to make a small reproducible test case first. Basically an
> HTML file with just the headline.

fc-match won't give proper results because it matches in a different way than WebKit. WebKit will walk down the font list until it matches a font with the same name. So it won't use "DejaVu Sans" here because it doesn't have the same name as "Segoe UI" or whatever font it matched. You might try doing the same thing manually, though I suspect the issue is with Helvetica or Arial.

[Carlos Alberto Lopez Perez]

I have uploaded a simple test case here: http://people.igalia.com/clopez/wkbug/140290/test.html

Seems that the issue is related with the Helvetica font.

$ fc-match Helvetica
texgyreheros-regular.otf: "TeX Gyre Heros" "Regular"

$ Tools/jhbuild/jhbuild-wrapper --gtk run fc-match Helvetica
helvR12-ISO8859-1.pcf.gz: "Helvetica" "Regular"

After moving /usr/share/fonts/X11/{75,100}dpi/helv* to a tempdir, fc-match from the jhbuild returns:

$ Tools/jhbuild/jhbuild-wrapper --gtk run fc-match Helvetica
qhvr.pfb: "TeXGyreHeros" "Regular"

And now the text looks correct.

[Carlos Alberto Lopez Perez]

Michael comments that just doing "cp WebKitBuild/DependenciesGTK/Root/share/fontconfig/conf.avail/70-no-bitmaps.conf WebKitBuild/DependenciesGTK/Root/etc/fonts/conf.d/" fixes the issue.

Seems that most distros ship /etc/fonts/conf.d/70-no-bitmaps.conf, which explains why it works with the system fontconfig.

I'm marking this as a duplicate of bug 31931.

*** This bug has been marked as a duplicate of bug 31931 ***

[Michael Catanzaro]

(In reply to comment #10)
> fc-match won't give proper results because it matches in a different way
> than WebKit. WebKit will walk down the font list until it matches a font
> with the same name.

So what do we do when no font named Segoe UI exists? Why do we not want to use the same fonts that would be selected by fontconfig?

[Martin Robinson]

(In reply to comment #13)
> (In reply to comment #10)
> > fc-match won't give proper results because it matches in a different way
> > than WebKit. WebKit will walk down the font list until it matches a font
> > with the same name.
> 
> So what do we do when no font named Segoe UI exists? Why do we not want to
> use the same fonts that would be selected by fontconfig?

CSS has stricter rules about selecting fonts than fontconfig. Presumably page authors have a better idea of what fonts work with their page, so we give their font list priority, fist trying to find an exact match on the CSS list before falling back.

The details of our approach, which is follows Chromium's strategy can be found in Source/WebCore/platform/graphics/freetype/FontCacheFreeType.cpp.

[Sergio Villar Senin]

I think the same is still happening in http://edition.cnn.com/2015/01/13/travel/winter-photography-tips/index.html even with your patch in.

[Sergio Villar Senin]

(In reply to comment #15)
> I think the same is still happening in
> http://edition.cnn.com/2015/01/13/travel/winter-photography-tips/index.html
> even with your patch in.

Or http://www.rachelandrew.co.uk/archives/2014/12/26/a-year-in-links/

[Martin Robinson]

(In reply to comment #16)
> (In reply to comment #15)
> > I think the same is still happening in
> > http://edition.cnn.com/2015/01/13/travel/winter-photography-tips/index.html
> > even with your patch in.
> 
> Or http://www.rachelandrew.co.uk/archives/2014/12/26/a-year-in-links/

I'm not seeing the problem here, so would you mind walking through the first two steps that I listed?

[Michael Catanzaro]

FWIW the fonts on both of those sites look the same (horrible) in Firefox as well.

[Sergio Villar Senin]

(In reply to comment #18)
> FWIW the fonts on both of those sites look the same (horrible) in Firefox as
> well.

Speak for yourself :), they look beautiful for me in FF.