User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:220.127.116.11) Gecko/20070914 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:22.214.171.124) Gecko/20070914 Firefox/126.96.36.199 I have just downloaded latest version of manfield and noticed, that it uses different rendering engine for font rendering which actually makes fonts look ugly and difficult to read (see attachments). Reproducible: Always Steps to Reproduce: 1. Run Manfield 2. Open i.e. http://www.mozilla.org/projects/minefield/ 3. It affects all pages, every time. Actual Results: Fonts are rendered incorrectly, doesn't look consistent with GNOME. Expected Results: Consistent font rendering - if I like mac os style of font rendering, I would like to see Firefox using it too. Version 188.8.131.52 works fine, but newest Manfield doesn't. more information about font rasterization: http://antigrain.com/research/font_rasterization/index.html
maybe this will help: (gecko:5298): Pango-WARNING **: failed to create cairo scaled font, expect ugly output. the offending font is 'Verdana 0' (gecko:5298): Pango-WARNING **: failed to create cairo scaled font, expect ugly output. the offending font is 'Verdana 0' (gecko:5298): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Verdana 0', text='Polish Dzień dobry, Hej' (gecko:5298): Pango-WARNING **: pango_font_get_glyph_extents called with null font argument, expect ugly output
Component: OS Integration → GFX: Thebes
Product: Firefox → Core
QA Contact: os.integration → thebes
Summary: new manfield uses wrong (unwanted) rendering engine for fonts → trunk uses wrong (unwanted) rendering engine for fonts
What output do you see from: "xrdb -query | grep -i Xft"? fontconfig can specify hinting too: does moving your ~/.fonts.conf make a difference.
[marek@Mareg ~]$ xrdb -query | grep -i Xft Xft.antialias: 1 Xft.dpi: 96.000000 Xft.hinting: 1 Xft.hintstyle: hintfull Xft.rgba: rgb [marek@Mareg ~]$ and moving ~/.fonts.conf makes firefox 184.108.40.206 fonts like in Trunk (ugly)
also need to set layout.css.dpi to 96 because Manfield (Trunk) makes fonts larger with layout.css.dpi set to 0 or -1
(In reply to comment #6) > also need to set layout.css.dpi to 96 because Manfield (Trunk) makes fonts > larger with layout.css.dpi set to 0 or -1 Yes, I suspect many people will be wanting to set that.
(In reply to comment #5) > and moving ~/.fonts.conf makes firefox 220.127.116.11 fonts like in Trunk (ugly) "ugly" is a matter of opinion - I and probably a few other people prefer well hinted fonts. But you can customize: "echo Xft.hintstyle: hintslight | xrdb -merge" should give you something close to what you prefer. To set this more permanently, I believe gnome has a setting for it or I hope gnome reads ~/.Xresources. The difference between 18.104.22.168 and trunk is probably that 22.214.171.124 selected helvetica (and maybe your ~/.fonts.conf mapped that to something else) but trunk uses fontconfig's default sans-serif (fc-match -v sans-serif). If this is different to other GNOME apps then I guess you've (or someone else has) specified a different font for GNOME/gtk. You can specify the same font in Mozilla preferences if you like, or .fonts.conf can be used to specify your preference for sans-serif.
I don't think it is the matter of chosen font as it applies to all fonts rendered on the page - basically I use different FreeType - taken from http://avi.alkalay.net/linux/docs/font-howto/Font.html#freetype - which makes fonts look more natural. Please look at attached screenshots and compare text in bold - it's basically the same font, but rendered using different rendering engine. That one which looks more natural (usually called "Adobe style") is my preferred rendering engine, other one (usually called "Microsoft style") is not what I like to see. Unfortunately switching to 'hintslight' doesn't solve a problem as Trunk still uses wrong rendering engine (it looks better though). All my Gnome Apps are rendering fonts in the way I want and I like it, and would love to see Trunk to behave in the same way.
ok, as it still uses wrong font rendering engine the actual output looks much better. is there an easy way to force Trunk to use system default font rendering engine?
Trunk will use freetype from your system. The only component different in the font rendering stack is a different cairo, but I doubt that is the issue. I can see the difference in the screen shots but its hard to tell whether exactly the same font is used. Try Xft.hintstyle: hintmedium. What was it in your fonts.conf that changed the behavior of firefox 126.96.36.199?
(In reply to comment #11) > Trunk will use freetype from your system. The only component different in the > font rendering stack is a different cairo, but I doubt that is the issue. Cairo may be the issue. I did some comparison between cairo 1.4 (usually what's shipped on recent distributions) and cairo 1.5 (more or less what is included in Firefox) and there is a difference in rendering: see bug 375591 comment 6. This is what makes the font look thinner, in particular when using freetype bytecode interpreter for hinting (default on Ubuntu). bug 404637 may also be of interest
(In reply to comment #5) > [marek@Mareg ~]$ xrdb -query | grep -i Xft > Xft.antialias: 1 > Xft.dpi: 96.000000 > Xft.hinting: 1 > Xft.hintstyle: hintfull > Xft.rgba: rgb > > and moving ~/.fonts.conf makes firefox 188.8.131.52 fonts like in Trunk (ugly) So it sounds like part of the issue here is that X resource settings are (incorrectly) taking priority over fontconfig settings, which is https://bugs.freedesktop.org/show_bug.cgi?id=11838 Changes in bug 385263 should resolve that issue. The remaining issues (comment 12) I think are covered by bug 404637.
Assignee: nobody → mozbugz
Status: UNCONFIRMED → ASSIGNED
Depends on: 385263
Ever confirmed: true
Changes in bug 385263 mean that fontconfig settings for hintstyle now take precedence over X resource settings (as they did for Xft). But Mozilla's cairo is not yet built with lcdfilter support, which is bug 404637.
Status: ASSIGNED → NEW
Depends on: 404637
Bug 404637 has also been fixed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.