Summary: | [GTK] Pixelated fonts used for Engadget headline | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Xabier Rodríguez Calvar <calvaris> | ||||||
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED DUPLICATE | ||||||||
Severity: | Normal | CC: | cgarcia, clopez, mcatanzaro, mrobinson, svillar | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Created attachment 244338 [details]
Rendered in Chromium
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. 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. (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. (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/ (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. (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. (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" (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. (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. 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. 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 *** (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? (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. 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. (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/ (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? FWIW the fonts on both of those sites look the same (horrible) in Firefox as well. (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. |
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.