Bugzilla – Bug 104365
LCD font hinting broken
Last modified: 2019-05-22 00:41:39 UTC
Start gedit2 & xmag, start the nice font capplet. Switch font to 'monochrome' - this should (as can be seen in the preview) have a marked effect on the desktop. Note that nothing happens to the applications as you select it. re-start gedit2 - notice - still no change. use some of the other settings, LCD, etc. and - no cookie. I wouldn't mind - since the default is quite nice - but, it's not the default that OO.o is using - and, since the settings don't work it's hard to unwind exactly what the default should be - and how we can mirror that.
it's worth adding - that this also doesn't work for me in NLD - wrt. the various LCD / cleartype tweakings that are possible - however, the monochrome/best/whatever switch does have a noticable & almost instant effect.
Is your ~/.fonts.conf modified proerly?
It seems, that .fonts.conf is not created. I don't know, whether new gtk still uses this way or not, but confirming that the gnome-font-properties does not change settings.
I have no ~/.fonts.conf - but I thought that the settings were propagated via xsettings to the various apps (but I guess perhaps that could be just an update notification).
So - to confirm xrdb -query | grep Xft shows that the control-center piece, and the gnome-settings daemon are propagating the settings change around the place. The mystery is that gtk+ would (somehow) not use them. Interestingly the gnome-termainal (internal) font obeys the settings just fine - chasing ...
urgh - of course, it turns out I have a custom build of gtk+ installed - and it's entirely possible I screwed that up somehow - you're certain you see this on your box Stanislav ?
Yes, I don't see any change while changing hinting setting.
gtksettings.c does call gtk_rc_reset_styles in response to the settings change - as expected, unfortunately the rendering doesn't update.
We are using Xft for rendering - right ? and not the plain ft2 backend ?!
Not sure how cairo does things.
curiously this works fine with my personal build of gtk+ / cairo HEAD - it's also something that should have been fixed recently in cairo/gtk+ - so ... really unclear how this is not working in our builds. Perhaps worth ignoring for now & re-testing in B2 with a later pango/cairo/gtk+
So - this is still broken in Beta 2...
still broken in B3 ... re-titling / bumping priority.
Hmm, there are some very recent changes around cairo/pango/gtk+; this may have been fixed very recently.
Rodrigo, do you have an up to date jhbuild to test in?
problem is - it has worked for me for a while in a self-built setup ;-) just not in the packaged foo - no idea why.
Right, this works great from CVS. So maybe we are missing some cairo/gtk/pango update?
Just to confirm - not functional in a B4 install either.
From the gtk+-2.8.3 announcement last Monday: * Fix problems with the handling of initial settings for font options and cursor themes [Frederic Crozat, Joe Markus Clarke, Owen Taylor, Kjartan Maraas] ... so maybe we just need an updated package. (Sorry, I don't know the details of what this fixes)
We switched now to 2.8.3, so this should be fixed in RC1.
Rodrigo could you retest with gtk 2.8.3? There is also bug 114770 that might also be solved.
2.8.3 has not solved the issue.
The reason this bug occurs is that antialiasing and subpixel ordering options are set in fonts.conf (or more specifically, in suse-pre-user.conf). This means that the XResources set by gnome-font-properties are ignored, since fonts.conf takes precedence (Since, for example, some people want to be able to not antialias fonts below a certain pixel size.) The solution is to remove these sections from fonts.conf. fontconfig has these set to a default value, so that should be fine. If not, we could go in and change the default values in fontconfig instead of adding these hacks in fonts.conf. For some reason, when I test this on my box, this doesn't fix subpixel ordering. I can turn off antialiasing, but I can't control whether it's greyscale aa or subpixel and what the subpixel order is.
Moving to fontconfig maintainer
Add Michael Schröder <mls@suse.de> to CC:.
Chris> The solution is to remove these sections from fonts.conf. I don't think this is a good solution. Certainly not for the sub-pixel Chris> hinting. Chris> fontconfig has these set to a default value, so that should be Chris> fine. Fontconfig sets this to a default value, but depending on the monitor which is connected. On most TFT displays, sub-pixel hinting would default to on. Many people didn't like this. See also bug #59409. The default value for Anti-aliasing also seems to depend on the type of display connected, I'll check on which types of displays it default to true now ...
*** Bug 116536 has been marked as a duplicate of this bug. ***
*** Bug 115952 has been marked as a duplicate of this bug. ***
By the way, the Xft.dpi value set by gnome-font-properties seems to default to 96 dpi always. Why doesn't it default to the true dpi value of the display, which is 112 dpi on my machine: mfabian@magellan:~$ xrdb -query | grep Xft Xft.antialias: 1 Xft.dpi: 96.000000 Xft.hinting: 1 Xft.hintstyle: hintfull Xft.rgba: rgb mfabian@magellan:~$ xdpyinfo | grep resolution resolution: 112x112 dots per inch mfabian@magellan:~$ Currently it looks like I have to enter the correct dpi setting manually in the "Details" dialog of gnome-font-properties.
I think GNOME should not use the X-resources but use the config file ~/.fonts.conf instead, just like KDE does. The KDE control centre reads ~/.fonts.conf in order to keep manually edited user settings and then adds the settings selected in the KDE control centre and write ~/.fonts.conf again. That means, you will run into the same problem anyway if a user has changed these settings using the KDE control centre and then uses GNOME. It doesn't matter whether these values are set in /etc/fonts/... or in ~/.fonts.conf, if these values are found in any config file read by fontconfig, they are used as written in the config file and the X-Resources are ignored. Ideally, changes to the fontconfig configuration done in KDE should also affect GNOME and vice versa. Currently this will not work because GNOME only uses the X-resources and remembers the settings in ~/.gconf/ and KDE uses ~/.fonts.conf. Therefore, settings done in KDE will affect GNOME and render the X-resources used by GNOME useless. But settings done in GNOME will have no effect whatsoever on KDE.
Mike - how does KDE do desktop-wide change notification of this ? or are the settings effective only on re-start (of each application) ? or does every app have a FAM monitor on the file or something ? Clearly the XSetting approach is rather useful for instant-apply & evaluating your choice on the desktop now ?
Apparently KDE does *not* have desktop-wide change notification for this. The settings are effective only on restart of each application. I.e. if you restart e.g. konsole, you will see the effect there but not yet in the KDE taskbar ("kicker"), icons on the desktop, ... Of course one can restart all these applications individually but usually it is easier just to restart KDE.
Michal Meeks> or does every app have a FAM monitor on the file or something ? No. Currently nothing happens immediately in KDE if ~/.fonts.conf is changed.
Michal Meeks> Clearly the XSetting approach is rather useful for Michal Meeks> instant-apply & evaluating your choice on the desktop Michal Meeks> now ? Yes, but only a limited set of options can be set by the X-Resources. Jürgen Weigert <jw@suse.de> yesterday had the idea that one could combine the approaches: The GNOME applications apparently have code to react when a Xft.* resource is changed. Maybe such a change of an X-resource could be used to trigger a re-initialization of fontconfig, i.e. a rereading of the config files? If that works, GNOME could write all setup into ~/.fonts.conf just like KDE does (even complicated setup which is not possible with X-resources becomes possible then) but continue to use the X-resources for the limited options they support. Because the same options are also in the config file then, the value of the X-resources would be ignored but the X-resources could be used as a trigger indicating that a re-initialization is necessary.
Yesterday I checked with strace that the fontconfig setup files are not read again by GNOME applications when the Xft.* X-resources are changed by gnome-font-properties. But isn't it possible to achieve that?
More on antialiasing: http://lists.freedesktop.org/archives/cairo/2005-September/005339.html http://lists.freedesktop.org/archives/cairo/attachments/20050920/8bc7e9c6/attachment-0001.mht
I don't think comment #36 is relevant for the problem discussed here.
*** Bug 113838 has been marked as a duplicate of this bug. ***
*** Bug 161256 has been marked as a duplicate of this bug. ***
going back to #30: GNOME control center has to write out a ~/.fonts.conf to make the setting persistent. I can understand it writes X resources for instant apply, but fontconfig sees fonts.conf overruling Xft resources. But if this has anything to do with fontconfig, then a way to signal instant apply on change of ~/.fonts.conf, but I think this is still a GNOME enhancement as the applications using fontconfig would need to retrigger their font caches.
In GTK+, changing the font options works like this: 1. The control center frobs the XSettings 2. Each GTK+ app picks up the notification, and runs gtksettings.c:settings_update_font_options(). I'd set a breakpoint here and see what value we get for the RGBA smoothing option. Those options get set on the corresponding GdkScreen. 3. gtksettings calls gtk_rc_reset_styles(), which eventually calls gtk_widget_reset_rc_styles() on each toplevel window. 4. Each toplevel window recurses within its children. gtk_widget_reset_rc_style() should get called for each widget in the app. 5. gtk_widget_reset_rc_style() calls gtk_widget_set_style_internal(), which calls gtk_widget_update_pango_context(). 6. gtk_widget_update_pango_context() takes the PangoContext for a widget, pulls the new values from the GdkScreen, and sets those values on the PangoContext. 7. The widget gets repainted eventually, since gtk_widget_set_style_internal() calls gtk_widget_queue_resize(). There are various conditions in (5) and (6) that could cause things not to get updated, but those shouldn't be the reason for this problem. I'd take note of the values that we get in (2), and later compare them to the values that Pango gets eventually after (7). I don't know if it's re-reading some Fontconfig options from the system configuration files, which may overwrite the settings from (2).
Federico - I'd put good money on the KDE "just update the master file that clobbers the settings" approach breaking the GNOME setting. When I last dug at it, the right set of things happened as you traced above, but it still ended up getting clobbered [ most prolly inside fontconfig ]
I've traced the process of changing font options, as described in comment #41: - GTK+ gets the right options in gtksettings.c:settings_update_font_options(). - The settings propagate correctly down to the actual call to cairo_ft_font_options_substitute(): that function takes in a cairo_font_options_t, and it has the right values for antialiasing/rgba/etc. ... but later, FcFontSort() gives me a fontset which doesn't respect that information. In summary: when you change the font rendering options in the control center, GTK+ and Pango request the right values from cairo/fontconfig. But Fontconfig returns stuff which doesn't respect those values. I don't know if this is due to what is described in comment #23. Can someone who knows how fontconfig works please confirm this? [Why is this a problem only in Suse?]
(In reply to comment #42) > Federico - I'd put good money on the KDE "just update the master file that > clobbers the settings" approach breaking the GNOME setting. When I last dug at > it, the right set of things happened as you traced above, but it still ended up > getting clobbered [ most prolly inside fontconfig ] To clarify: this is *not* about GNOME/KDE interop. This is about getting the font settings to work at all in our GNOME setup.
Mike? See comment 43
Federico> In summary: when you change the font rendering options in the control center, Federico> GTK+ and Pango request the right values from cairo/fontconfig. But Fontconfig Federico> returns stuff which doesn't respect those values. I think that is because the values set in config files override values set in Xresources. I.e. these Xresources set by gnome-font-properties fabian@magellan:~$ xrdb -query | grep Xft Xft.antialias: 1 Xft.dpi: 96.000000 Xft.hinting: 1 Xft.hintstyle: hintfull Xft.rgba: bgr mfabian@magellan:~$ will be completely ignored if any of these values is set in a config file, i.e. either somewhere in /etc/fonts or in ~/.fonts.conf. If you use the KDE control centre to change some font settings, KDE will write values for antialias, hinting, hintstyle, and rbga into ~/.fonts.conf. After that the Xresources are ignored.
I have two machines (a laptop, and a desktop with an lcd monitor) with identical /etc/fonts/ directories. Both have: <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="hintstyle"> <const>hintfull</const> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> in /etc/fonts/suse-hinting.conf. Neither has a ~/.fonts.conf. And yet, on the desktop machine, fonts are hinted, and on the laptop they are not (regardless of anything I've tried setting in gnome-font-properties.)
(In reply to comment #46) > I think that is because the values set in config files override values > set in Xresources. This is not about config files nor Xresources. This is about calling functions to explicitly set the RGBA options from the code, and fontconfig not using those values at all.
Federico, please drive this with Mik.
OK. The problem in GNOME is that you change your RGBA or antialiasing parameters in gnome-control-center, but those changes don't show up in running GTK+ applications. The apps get the change notification just fine, and they receive the right parameters, which are what the user configured in the control center. We pass those correct parameters down to Cairo, and it even passes them down to Fontconfig. But when getting the final fontset with FcFontSort(), it gives me fonts that don't match what I just configured. The application repaints, but it looks as if nothing happened. What I'm asking is if there's a reason for my parameters being overriden: /* gets the right value for antialias_parameter */ FcPatternAddBool (pattern, FC_ANTIALIAS, antialias_parameter); /* gets the right value for rgba_parameter */ FcPatternAddInteger (pattern, FC_RGBA, rgba_parameter); FcDefaultSubstitute (pattern); patterns = FcFontSort (NULL, pattern, FcTrue, NULL, &result); /* why do the fonts don't use my antialias_parameter nor rgba_parameter here? */
Federico> This is not about config files nor Xresources It is because: FcPatternAddInteger (pattern, FC_RGBA, rgba_parameter); achieves the same as a rule like <match target="pattern" > <edit mode="assign" name="rgba" > <const>none</const> </edit> </match> in a config file. But this will be overridden by a rule matching on "font" in a config file: <match target="font" > <edit mode="assign" name="rgba" > <const>rgb</const> </edit> </match>
*** Bug 59409 has been marked as a duplicate of this bug. ***
I read bug #59409 to look at the history of changes in our fontconfig configuration. Then I looked for "edit" clauses in our configuration, and played with them a bit to see what changes need to be done for gnome-font-properties to work (that's the font options dialog in gnome-control-center): 1. When one selects subpixel smoothing, it doesn't work. /etc/fonts/suse-pre-user.conf (included from fonts.conf) has the following: <!-- turn off subpixel rendering by default --> <match target="font"> <edit name="rgba" mode="assign"> <const>unknown</const> </edit> </match> This means "don't ever use subpixel smoothing". By removing this, subpixel smoothing works fine in gnome-control-center. 2. When one turns antialiasing on and off, it doesn't work. /etc/fonts/suse-hinting.conf (included from fonts.conf) has the following: <!-- Using the autohinter and anti-aliasing. This is a good default for most fonts. --> <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> This means "always use the autohinter, and always use antialiasing". Removing this section makes antialiasing on/off work in gnome-control-center; changing the hinting options works as well. So, by removing those sections, everything seems to work. I don't think our stock configuration should be forcing a particular scheme on users, or much worse, prevent them from changing the options easily in the GUI. One pending thing is that if you select subpixel smoothing, horizontal_rgb and horizontal_bgr produce the same results. Vertical_rgb and vertical_bgr produce different results from horizontal subsampling, but they both look the same to each other. I'm not sure if this is a rendering bug in freetype or Xrender. Can we remove the sections mentioned above from our stock files in /etc/fonts? Bug #59409 mentions that the KDE control center supports all the options now, so I see no reason for this to be in the default configuration of fontconfig anymore.
Federico> /etc/fonts/suse-pre-user.conf (included from fonts.conf) has Federico> the following: Federico> Federico> <!-- turn off subpixel rendering by default --> Federico> Federico> <match target="font"> Federico> <edit name="rgba" mode="assign"> Federico> <const>unknown</const> Federico> </edit> Federico> </match> Federico> Federico> This means "don't ever use subpixel smoothing". By Federico> removing this, This part is already gone since April 11th, apparently you are not testing the latest version: rpm -q --changelog fontconfig [...] * 火 4月 11 2006 - mfabian@suse.de - Bugzilla #59409: don't set a default value for rgba at all, rely on the auto-detection instead. Previously it was impossible to switch subpixelhinting off in the KDE control centre if it had been switched on by the auto-detection. But in the meantime this has been fixed in KDE, therefore we don't have a reason anymore to override the auto-detection. Federico> subpixel smoothing works fine in Federico> gnome-control-center. Not really because it is enough to call the KDE control centre and tweak any font related setting *once* and you will have a ~/.fonts.conf file which sets values for "rgba", "hinting", "hintstyle" and "antialias" (using <match target="font" >...). As soon as that happened, it will stop working in that gnome-control-centre.
concerning comment #53: Federico> <match target="font"> Federico> <edit name="autohint"> Federico> <bool>true</bool> Federico> </edit> As there is no way to set "autohint" via a GUI at all, neither in the gnome-font-properties nor in the KDE control centre, I think that this rule in suse-hinting.conf should certainly stay. For most fonts autohinting works much better than using the byte code interpreter (autohint=off -> byte code interpreter is used). We should set a good default. Even more so if it is not possible to edit it in the GUI. Not there there are some fonts where the autohinter *must* be turned off, see the rule <match target="font"> <test name="family"> <string>MingLiU</string> <string>PMingLiU</string> </test> <edit name="autohint"> <bool>false</bool> </edit> </match> in suse-hinting.conf. These fonts absolutely *require* the use of the byte code interpreter, without it the rendering results will be complete garbage. How to set this in a GUI? And even if you could set a value for autohinting in the GUI it would not be enough. It is needed to limit switching it off to certain fonts. Why switch if off for all fonts and loose a lot of quality for most fonts just because it doesn't work well with MingLiU and PMingLilU and Likhan?
What I wrote in comment #53 shows that it is necessary to use <match target="font"> quite often for rendering related settings because some settings may be good for certain fonts only and disastrous for other fonts. Another example is the rule: <!-- The following rule sets up black and white rendering with the byte code interpreter for a small list of fonts which are known to have good byte code and give bitmap quality results at small sizes. The pixelsize limit is set to '0' though, which effectively disables this rule by default because most users don't like that bitmap look and feel. If you like a bitmap look and feel of your desktop, copy this rule into your ~/.fonts.conf file and replace the '0' with non-zero pixelsize limit. Using '18' as the pixelsize limit is a good choice if you have the fonts in this list installed and like a bitmap look and feel. --> <match target="font"> <test name="family"> <string>Andale Mono</string> <string>Arial</string> <string>Comic Sans MS</string> <string>Georgia</string> <string>Impact</string> <string>Trebuchet MS</string> <string>Verdana</string> <string>Courier New</string> <string>Times New Roman</string> <string>Tahoma</string> <string>Webdings</string> <string>Albany AMT</string> <string>Thorndale AMT</string> <string>Cumberland AMT</string> <string>Andale Sans</string> <string>Andy MT</string> <string>Bell MT</string> <string>Monotype Sorts</string> </test> <test name="pixelsize" compare="less_eq"> <double>0</double> </test> <edit name="autohint"> <bool>false</bool> </edit> <edit name="antialias"> <bool>false</bool> </edit> </match> in suse-hinting.conf. This rule is disabled by default (note the comparison with pixelsize 0) but it can be enabled by setting a limit in /etc/sysconfig/fonts-config in the variable BYTECODE_BW_MAX_PIXEL="0" Setting this limit to 18 achieves the same as the default settings on Windows XP: antialiasing off up to 18 pixel and byte code interpreter on. This achieves a rendering like high quality bitmaps. Some people like that very much and absolutely insist on using that, others hate it with passion. Anyway, even for users who like this setting, it does makes sense only for the Microsoft Webfonts and the Agfa fonts. For all other fonts it doesn't make any sense whatsoever. Therefore, <match target="font"> has to be used here as well <match target="pattern"> won't work if you want to limit the effect to certain fonts.
In the long run, I think the GUIs in Gnome and KDE should offer more advanced options like limiting some settings to certain fonts. And of course choosing whether to use the autohinter or not. And, I think Gnome should stop to use the X-resources because complicated, advanced settings cannot be done with the X-resources anyway, only with a config file like ~/.fonts.conf. Therefore, I think it would be better if gnome-font-properties read ~/.fonts.conf and wrote changed settings back to ~/.fonts.conf, just like the KDE control centre does. Of course changes done manually by the user should be preserved because an expert user might have written rules to ~/.fonts.conf which are impossible to do with the GUI. This works in the KDE control centre already, the contents of ~/.fonts.conf are parsed and when writing back ~/.fonts.conf the rules added manually by the user are preserved.
A problem with using ~/.fonts.conf to change settings is that there seems to be no way currently to get these settings applied *instantly*. If you change any rendering settings in the KDE control centre, you get a pop-up box that you will see the changes only in newly started applications. But maybe fontconfig can be improved here so that it becomes possible to trigger parsing of all config files again for already running applications. I'm not sure. Anyway, I think instant application is less important than the possibility to use advanced rules in ~/.fonts.conf.
An 'advanced' GUI that allows one to tweak thousands of (irrelevant to 99% of users) options is unlikely to fly [ at least in GNOME ]. The examples given above "it makes no sense to set XYZ for ABC font" are fine as they are clearly useful anyway - what we're interested in is setting the default look for all fonts that are not annotated in such a way. It is quite unfortunate that the recent KDE development in this area has been integrated without any reference to the fact that it breaks GNOME. I suspect that a similarly architected 'solution' whereby eg. on GNOME session start we delete ~/.fonts.conf is perhaps the simplest 'fix' for SLED given the available resources / time etc. Federico - I guess setting these options after reading the system config would effectively clobber them discarding the interesting corner-case annotation that Mike identifies.
Michael Meeks> what we're interested in is setting the default look Michael Meeks> for all fonts that are not annotated in such a way. I'm checking wether a compromise to achieve that is possible ...
I thought the using the following in /etc/fonts/suse-hinting.conf could possibly be a resonabble compromise: <!-- Using the autohinter, hintstyle=hintfull and anti-aliasing. This is a good default for most fonts. --> <match target="pattern"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="hintstyle"> <const>hintfull</const> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> I.e. set the default with <match target="pattern"> instead of <match target="font">. It is still possible to use additional rules with <match target="font"> to make exceptions for special fonts. And I had the hope that the FcPatternAdd<something> functions used by gnome might still work then. But when testing this idea, I found that it works nicely for gnome-terminal (settings like subpixel hinting selected in gnome-font-properties have an immediate effect on gnome-terminal) but it does *not* work for gedit. What is the difference between gnome-terminal and gedit?
(In reply to comment #61) > But when testing this idea, I found that it works nicely for > gnome-terminal (settings like subpixel hinting selected in > gnome-font-properties have an immediate effect on gnome-terminal) > but it does *not* work for gedit. > > What is the difference between gnome-terminal and gedit? Ignore gnome-terminal and the underlying vte for now - they use a different mechanism for picking up the updates to the font configuration, so VTE always seems to work. I think we have two bugs: 1. Making font configuration work in GNOME; that's this bug in particular. This should be easy to fix by removing the sections in suse-*.conf. [Is KDE hurt in any way by doing this?] 2. Making KDE and GNOME share the same mechanism for font configuration. We can wait until SP1 to fix this properly, since we'll have to figure out if we want to use a ~/.fonts.conf or not, or XSettings, or what. > I.e. set the default with <match target="pattern"> instead > of <match target="font">. But this will still prevent GTK+ from making its own run-time changes to the configuration. I think that's why it still doesn't work for you. GNOME lets you set these options in the first dialog of gnome-font-properties: - Fonts/sizes for several parts of the desktop. - High-level parameters: monochrome (no antialiasing), "best shapes" (antialiasing, medium hinting), "best contrast" (antialiasing, full hinting), "subpixel smoothing". And it has extra options in the Details dialog: - None / Slight / Medium / Full hinting. - Subpixel order (hrgb, hbgr, vrgb, vbgr). Those options seem to be fine for most users. Tweaking the hinting and antialiasing parameters on a per-font basis should be done at font installation time, I think - you don't want to disable things like the bytecode interpreter unless the font is buggy.
One thing to note: if we remove those sections from our fontconfig setup, this bug comes up: http://bugzilla.gnome.org/show_bug.cgi?id=307196 This happens in GTK+ or Pango or Cairo, because we get unhinted/noninteger metrics, but apps expect integers. I'm investigating it upstream.
Federico> This should be easy to fix by removing the sections in Federico> suse-*.conf. [Is KDE hurt in any way by doing this?] It doesn't hurt only KDE. You will have very bad defaults then everywhere. Without these rules in /etc/fonts/suse-hinting.conf you get by default: autohint=false hintstyle=hintmedium That looks extremly ugly for most fonts. I.e. with defaults like this, all users have to tweak the font settings immediately in the Gnome and KDE GUIs. Even worse, you cannot switch on autohint at all neither in the Gnome nor in the KDE GUI. Therefore at least the default setting of authohint=true has to stay in my opinion. That means that at least <match target="pattern"> <edit name="autohint"> <bool>true</bool> </edit> </match> should stay in suse-hinting.conf. The other options like hintstyle and antialias can be changed in the current GUIs. It is not very nice though as hintstyle will default to "hintmedium" then which also looks extremely ugly especially with the current version of freetype2. I think hintstyle=hintmedium never looked very nice but with freetype 2.1.10 and the hinting related patches we apply from upstream CVS it looks unbearably ugly. These patches improved the results for "hintfull" a lot, but on the other hand they made it worse for "hintmedium". Federico> I think - you don't want to disable things like the bytecode Federico> interpreter unless the font is buggy. It is certainly better to disable the byte code interpreter for the vast majority of fonts. That is also the opinion of the Freetype2 developers. The reason is that only a handful of fonts has useful byte code at all. Apparently it is a huge task to add good byte code to fonts, therefore it is almost never done. There are only a handful of fonts where it really helps which are those already listed in suse-hinting.conf (see the list in comment #56), i.e. the Microsoft Webfonts and the Agfa Fonts (which are basically the same as the Microsoft Webfonts) and a few Asian fonts which absolutely *require* the byte code interpreter because they use byte code to assemble glyphs from smaller components. For all other fonts, switching on the byte code interpreter makes the rendering worse. And even for the Microsoft webfonts and the Agfa fonts, enabling the byte code interpreter only helps when rendering black and white (i.e. antialias=false). With anti-aliasing, the byte code makes the results worse even for those fonts. The byte code in these fonts was apparently designed to achive bitmap quality at small sizes without anti-aliasing, for other cases it doesn't help.
I guess if we used <match target="pattern"> in suse-hinting.conf to set the defaults, you could override those with FcPatternDel (pattern, FC_ANTIALIAS); FcPatternAddBool (pattern, FC_ANTIALIAS, antialias_parameter); The second line alone is not enough but when first deleting the pattern element, adding it again should work. Federico> Ignore gnome-terminal and the underlying vte for now - they use a Federico> different mechanism for picking up the updates to the font Federico> configuration, so VTE always seems to work. When looking into the source code of vte to see what it does differently, I found that it uses FcPatternDel before FcPatternAdd... I have not yet tested this but I guess this is the important difference.
Created attachment 80863 [details] bugzilla-104365-cairo.patch Patch for cairo.
Created attachment 80864 [details] bugzilla-104365-fontconfig.patch patch for suse-hinting.conf in "fonts-config" and "fontconfig".
With the patches from comment #66 and #67, we can still set a default for the hinting options and nevertheless override the default using gnome-font-properties.
Note that it still does *not* work in the text window of gedit, only in the menus of gedit. Looks like the text window of gedit doesn't use the part of cairo which I tried to patch. Or maybe it doesn't use cairo at all?
I have submitted a "fonts-config" package with the change in comment #67 to NOARCH because this change has no disadvantages whatsoever. It still sets reasonable defaults but makes it easier to overrride them from applications.
I also submitted a "fontconfig" package with the same change as in comment #67 to STABLE. This change is not so important as the /etc/fonts/suse-hinting.conf file contained in the "fontconfig" package will be overridden anyway during the first run of "SuSEconfig --module fonts". I.e. this changes makes only a difference if SuSEconfig has not yet been run.
Created attachment 81424 [details] pango-104365-use-hinted-metrics.diff This is the patch I'll use for Pango.
Submitted Pango to autobuild. * Tue May 02 2006 - federico@novell.com - Added pango-104365-use-hinted-metrics.diff to fix the Pango-related part of https://bugzilla.novell.com/show_bug.cgi?id=104365. This makes Pango request hinted font metrics from Cairo/Fontconfig, even when we are using unhinted rendering. This is what applications expect; they would draw overlapping glyphs otherwise.
Thanks for the update to fontconfig! It works much better now. With the new fontconfig package and a patched cairo package from comment #66, I can change every property except antialiasing. My fonts are always antialiased, and there is no way to disable that in the GUI.
Federico, Monochrome still seems to have no effect for me but subpixel and best shape i see a difference.
Federico, what exactly does the patch for Pango attached to comment #72 achieve? I don't understand it yet.
Federico> With the new fontconfig package and a patched cairo package from Federico> comment #66, I can change every property except antialiasing. My Federico> fonts are always antialiased, and there is no way to disable that in Federico> the GUI. Are you sure you are using the cairo patch from comment #66? (Apparently you did not submit that patch to autobuild yet. Should I do that?). On my system, choosing monochrome in gnome-fonts-properties works, the fonts in the menu of gedit are really rendered monochrome then. But, as I mentioned in comment #69, this has no effect on the text window of gedit, only on the menus of gedit.
(In reply to comment #76) > Federico, what exactly does the patch for Pango attached to comment #72 > achieve? I don't understand it yet. Oh, it's a bug fix in Pango. If you disable hinting, some glyphs get overlapped when apps paint them (especially underlined glyphs in Evolution). The upstream bug is this: http://bugzilla.gnome.org/show_bug.cgi?id=307196 (We did not see that bug before because there was effectively no way to disable hinting.)
(In reply to comment #77) > Are you sure you are using the cairo patch from comment #66? > (Apparently you did not submit that patch to autobuild yet. Should > I do that?). Sorry, I thought you would submit it :) I can certainly do that today. I'm pretty sure I tested this with that patch in my own build of Cairo, but let me double-check; I'll reply in a few minutes. I only need the updated fontconfig, and the patched Cairo package, right? > But, as I mentioned in comment #69, this has no effect on > the text window of gedit, only on the menus of gedit. That may be a bug in GtkSourceView (the widget which Gedit uses for its text area); I'll take a look.
Federico> Sorry, I thought you would submit it :) Sorry, this was a misunderstanding. I have just submitted it.
Federico> Oh, it's a bug fix in Pango. I see. Thank you for the explanation.
Nope, same thing :( With the updated fontconfig and cairo, I can change every parameter except turn off antialiasing.
My suse-hinting.conf still has this: <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> By removing the "antialias" part, I can turn antialiasing on and off just fine in gnome-font-properties.
Strange, because both fontconfig and fonts-config have <!-- Using the autohinter, hintstyle=hintfull and anti-aliasing. This is a good default for most fonts. Match on "pattern" for the default, not on "font" to make it easier to override the default using FcPatternDel() and FcPatternAdd...() (see bugzilla #104365). --> <match target="pattern"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="hintstyle"> <const>hintfull</const> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> now in suse-hinting.conf or suse-hinting.conf.template respectively. As you don't even have the "hintstyle" part, you fontconfig package must be rather old. The important package to update is fonts-config because the Perl-script /usr/sbin/fonts-config from that package is called by SuSEconfig (--module fonts) and will overwrite /etc/fonts/suse-hinting.conf starting with the template found in /usr/share/fonts-config/suse-hinting.conf.template and editing that template according to the settings in /etc/sysconfig/fonts-config. Probably you didn't update fonts-config?
Bah, I'm an idiot - indeed I had not updated fonts-config. Sorry about that :) With all the updated stuff (fontconfig, fonts-config, cairo, pango), all the properties can be changed correctly. Thanks for looking into this, Mike :)
cairo bugzilla-104365.patch was not upstreamed and it is commented out now. Can anybody check the status for cairo-1.4.0? I have just ported this patch and applying to STABLE. Searching in archives, it was added with following ChangeLog entry: Fri Apr 28 18:46:08 CEST 2006 - mfabian@suse.de - Bugzilla #104365: delete fontconfig pattern elements before trying to add them if the intention is to override default settings.
Stanislav asked to comment the patch. This patch makes the rendering settings from gnome-font-properties work. For example in case of the antialias option: Without the patch, cairo will add the antialias option to the fontconfig pattern only if it is not already there. But the option might already be in the pattern because a fontconfig setup file in /etc/fonts or ~/.fonts.conf adds it ot the pattern. With the patch, cairo first deletes the antialias option from the pattern unconditionally, then adds its own value of this option. Same for the other options like rgba, hinting, and hintstyle. When doing it like this, the settings in gnome-font-properties are preferred over any rules like <match target="pattern"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="hintstyle"> <const>hintfull</const> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> in a fontconfig setup file. I.e. such rules will then only set a default if nothing is set in gnome-font-properties or if a desktop different from gnome is used. If there are rules like <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> in a fontconfig setup file which match on "font" instead of "pattern", these rules will stil win over the settings in gnome-font-properties. Therefore, the default systemwide fontconfig setup in /etc/fonts should avoid using rules matching on "font" for setting options which can also be changed in gnome-font-properties.