Bugzilla – Bug 114949
It should be easier for the user to choose hinting styles, especially the byte code interpreter
Last modified: 2005-09-12 12:31:38 UTC
Currently it is not easy for a user to enable sharp black-and-white rendering using the byte code interpreter. Neither Gnome nor KDE currently offer options for this. It might be that such options can be added sometime, but I don't believe this can be done soon. Currently a user who wants to enable this has to write suitable rules into his ~/.fonts.conf file manually. The rules needed are not completely trivial, hard to understand for beginners and it is easy to make mistakes. Therefore I believe it is helpful to add additional variables in /etc/sysconfig/fonts-config which can be used to choose between the most important alternatives in hinting style easily.
See also bug #113637.
See also bug #114464.
I submitted a fontconfig package with a slight rearrangement of the config files to STABLE: ------------------------------------------------------------------- Fri Sep 02 14:37:28 CEST 2005 - mfabian@suse.de - Bugzilla #114949: move the rules to setup the hinting and anti-aliasing and the rules to enable embedded bitmaps from suse-pre-user.conf into seperate files and include these from suse-pre-user.conf. This makes it easier to edit or replace these rules with SuSEconfig.fonts according to values of variables in /etc/sysconfig. ------------------------------------------------------------------- This does *not* change anything so far, but it makes it easier to tune the setup automatically with SuSEconfig.fonts. I will now improve SuSEconfig.fonts to offer some tuning options.
Take a look there : http://www.opensuse.org/index.php/Optimal_Use_of_MS_TrueType_Core_Fonts_on_SuSE I'm writing a WIKI topic about MS TrueType Core Fonts rendering if you like this kind of rendering. As discussed with Mike Fabian, perhaps I will suggest a bug against SuSE main documentation as it is really important to be happy with its fonts.
First of all, thanks a bunch for not having to re-compile freetype2 in order to get bytecode enabled! Am I right that when using MS TT-fonts bytecode is the better option, whereas when using non TT-fonts autohinting is the better choice? I use MS TT-fonts and had to disable auto-hinting in /etc/fonts/suse-pre-user before I got the wanted results. Another problem is that konqueror uses Nimbus as default font and not (Sans-)Serif, so if one disables autohinting, one gets ugly fonts when browsing. I would suggest two things: - First, when installing MS-Fonts via YOU, also disable autohinting, as it seems to prevent bytecode from being used. - Second, change konqueror to default to (Sans-)Serif and not Nimbus. As far as I know, this would not change anything for users not using MS TT-fonts, but make the web much nicer for those who do. Kcontrol > Fonts already does default to (Sans-)Serif so I do not see any reason why konqueror should behave differently.
improved fonts-config package submitted to NOARCH: ------------------------------------------------------------------- Tue Sep 06 18:45:57 CEST 2005 - mfabian@suse.de - Bugzilla #114949: add a variable in /etc/sysconfig/fonts-config to choose whether black and white rendering using the byte code interpreter should be used and up to which pixel size. ------------------------------------------------------------------- There is the following new variable now in /etc/sysconfig/fonts-config: ## Path: Desktop ## Description: Display font configuration ## Type: integer ## Default: 0 # # Fonts which have high quality byte code interpreter instructions # can look very good in small sizes when rendered in black and white # (no anti-aliasing!) using the byte code interpreter (not the autohinter!). # The results look as good as high quality bitmap fonts. # # If you want to use this rendering style by default for all fonts # which are known to have good byte code instructions (these are the # fonts from the agfa-fonts package and the Microsoft webfonts), enter # an integer number greater than 0 here. For example, if you enter "18", # black and white rendering using the byte code interpreter will be used # for pixel sizes <= 18, for larger sizes the autohinter and anti-aliasing # will be used. You can disable this by entering "0". BYTECODE_BW_MAX_PIXEL="18"
A updated fonts-config package for testing is here: ftp://ftp.suse.com/pub/projects/m17n/10.0/noarch/fonts-config-20041001-8.noarch.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/src/fonts-config-20041001-8.src.rpm I would be grateful if you can test this as soon as possible. Thank you!
Half of it works, and half of it not yet solved. The package does not replace the suse-pre-user.conf, so I changed it back to default, i.e. autohinting=true and anti-alias=true. Anti-alias is disabled for small fonts and enabled for big fonts, so that part is solved. However, because of the autohinting=true, MS core fonts, which would benefit from bytecode the most, are still displayed very uglyly till I set autohinting=false manually in suse-pre-user.conf.
Apparently you still have an old version of the fontconfig package and therefore of suse-pre-user.conf. The current version should not contain any hinting settings. The current version just includes an extra file to setup the hinting and anti-aliasing: <!-- ************************************************************ --> <!-- Hinting and antialiasing --> <!-- ************************************************************ --> <include ignore_missing="yes">suse-hinting.conf</include> This extra file is written by the /usr/sbin/fonts-config (which is called by "SuSEconfig --module fonts").
The last changelog entry of your fontconfig package should look like: mfabian@magellan:~$ rpm -q --changelog fontconfig | head * 金 9月 02 2005 - mfabian@suse.de - Bugzilla #114949: move the rules to setup the hinting and anti-aliasing and the rules to enable embedded bitmaps from suse-pre-user.conf into seperate files and include these from suse-pre-user.conf. This makes it easier to edit or replace these rules with SuSEconfig.fonts according to values of variables in /etc/sysconfig. * 土 8月 20 2005 - mfabian@suse.de mfabian@magellan:~$ otherwise it is too old.
I have uploaded the current version of the fontconfig package (as in SuSE Linux 10.0 RC1) here for you to test: ftp://ftp.suse.com/pub/projects/m17n/10.0/i586/fontconfig-2.3.2.20050721-8.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/i586/fontconfig-devel-2.3.2.20050721-8.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/src/fontconfig-2.3.2.20050721-8.src.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/x86_64/fontconfig-2.3.2.20050721-8.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/x86_64/fontconfig-devel-2.3.2.20050721-8.x86_64.rpm Apparently you have something older than RC1. With the old version of the fontconfig package on your system, my new fonts-config script should make no difference at all as it only writes /etc/fonts/suse-hinting.conf which is not yet included by /etc/fonts/suse-pre-user.conf in the old version of fontconfig.
As RC1 is not yet released, I still had the old fontconfig-package. I updated it to the one given in comment 11. I re-started X. The suse-pre-user is now different, so I think that the new package installed correctly. I still had to set autohint=false in suse-hinting.conf in order to get clean fonts. I saw that there is a list of fonts that are supposed to be used with autohint=false, just below the general setting for autohint. Verdana is in the list and I think that Sans Serif links to Verdana, so it should have worked without me having disable autohint for all fonts. Sans-Serif is the font set in kcontrol for Desktop, Menu etc. Even if I change the font to be used from Sans Serif to Verdana in kcontrol, I still get the same ugly fonts as if autohint was enabled.
Works for me! Did you remember to set a pixel size limit in /etc/sysconfig/fonts-config? See comment #6: BYTECODE_BW_MAX_PIXEL="18" The default for this variable is "0". The byte code interpreter is only enabled for Verdana & Co. for pixel sizes smaller than that. I.e. "0" disables it. "0" is the default because most users want to disable it. To enable it, set this variable to a non-zero value, etc. "18". Then run "SuSEconfig --module fonts" and check the contents of suse-hinting.conf again. You should now see that the test <test name="pixelsize" compare="less_eq"> <double>18</double> </test> has been generated into the rule to enable the byte code interpreter for Verdana & Co. Before there was "0", which disables the rule.
That variable does not exist in the /etc/sysconfig/fonts-config file. I am running beta 4 here, so I guess I would have to install some more recent packages. I did already install fontconfig and fonts-config, as given in in the comments above. Regarding the ""0" is the default because most users want to disable it", I disagree. Why would people want to disable it, if it frees them of blury fonts? If users have installed MS-Fonts, then they have done so most likely because they expect them to look better than what is supplied by default. According to my experience they only look as clear, as they do with other OSs, if bytecode is enabled and autohint disabled. Further, those users knowing the fonts from Windows or MacOS will install them because they are used to their crystal clear edges from the time they used those OSs. Again those users would prefer the look they are used to. I might be wrong, but blury is worse than clear, so if clear is achievable for the used fonts, it should be default, hence autohint should be disabled and bytecode enabled as soon as MS core fonts are used. What happens if Sans-Serif is not in the list? Sans-Serif is not actually a font is it?, it's just a "link". Would the list fail for KDE when Sans-Serif rather than Verdana is set?
Sven> That variable does not exist in the /etc/sysconfig/fonts-config Sven> file. I am running beta 4 here, so I guess I would have to Sven> install some more recent packages. Sorry, that's my fault. I added to code to check this variable to the /usr/sbin/fonts-config script but I forgot to add the updated /etc/sysconfig/fonts-config template to the fonts-config package. Should be fixed now, please get the new fonts-config package from ftp://ftp.suse.com/pub/projects/m17n/10.0/noarch/fonts-config-20041001-8.noarch.rpm and try again. The last changelog entry should look like this: mfabian@magellan:/tmp$ rpm -qp --changelog fonts-config-20041001-8.noarch.rpm |head * 木 9月 08 2005 - mfabian@suse.de - Bugzilla #114949: + really add variable to enable the byte code interpreter to /etc/sysconfig/fonts-config. The last change contained only the code to use this variable if available but not the variable itself. + add variables in /etc/sysconfig/fonts-config to choose whether embedded bitmaps should be used and for which languages. mfabian@magellan:/tmp$ Thank you very much for testing!
Sven> Regarding the ""0" is the default because most users want to disable it", I Sven> disagree. Sven> Sven> Why would people want to disable it, if it frees them of blury fonts? It looks like the majority prefers to see the fonts anti-aliased. Sven> If users have installed MS-Fonts, then they have done so most Sven> likely because they expect them to look better than what is Sven> supplied by default. Yes, but many users seem to think that the MS-Fonts with anti-aliasing and the autohinter look very good. Sven> According to my experience they only look as clear, as they do Sven> with other OSs, if bytecode is enabled and autohint disabled. That's your opinion, but as far as I can tell not the opinion of the majority. Sven> Further, those users knowing the fonts from Windows or MacOS Sven> will install them because they are used to their crystal clear Sven> edges from the time they used those OSs. Again those users would Sven> prefer the look they are used to. You are right that on Windows XP the byte code interpreter and no anti-aliasing is used by default for pixelsize <= 18. I am not sure about Mac OSX, when I last tried I had the impression that it always uses anti-aliasing by default. Sven> I might be wrong, but blury is worse than clear, so if clear is Sven> achievable for the used fonts, it should be default, hence Sven> autohint should be disabled and bytecode enabled as soon as MS Sven> core fonts are used. I made this the default for beta1 but got a lot of negative feedback. Therefore I think it should not be the default. I would only make it the default again if somebody can really *prove* that a significant majority of users wants this rendering style by default. Somebody would need to conduct an opinion poll.
Sven> What happens if Sans-Serif is not in the list? Sans-Serif is not actually a Sven> font is it?, No, Sans-Serif is not a font, it is an alias which expands the the "best" sans-serif style font for the language you are currently using. Sven> it's just a "link". It is not really a "link". Have a look into /etc/fonts/suse-post-user.conf, there you will find something like: <alias> <family>sans-serif</family> <prefer> <family>Verdana</family> <family>Arial</family> <family>Albany AMT</family> <family>SUSE Sans</family> <family>Luxi Sans</family> <family>Mukti Narrow</family> <family>FreeSans</family> <family>Bitstream Vera Sans</family> <family>Nimbus Sans L</family> <family>Helvetica</family> <family>TSCu_Paranar</family> <family>BPG Glaho</family> <family>Terafik</family> <family>HGPGothicB</family> <family>IPAPGothic</family> <family>Sazanami Gothic</family> <family>Kochi Gothic</family> <family>FZSongTi</family> <family>FZMingTiB</family> <family>AR PL SungtiL GB</family> <family>AR PL Mingti2L Big5</family> <family>Baekmuk Gulim</family> <family>Baekmuk Dotum</family> </prefer> </alias> The topmost font on this list which is really installed *and* which supports the current language will be selected when "Sans Serif" is requested. You can check which font is really selected with 'fc-match'. For example: mfabian@magellan:~$ LC_CTYPE=en_US.UTF-8 fc-match "Sans Serif" verdana.ttf: "Verdana" "Regular" mfabian@magellan:~$ LC_CTYPE=ja_JP.UTF-8 fc-match "Sans Serif" hgjgbbmp.ttc: "HGPGothicB" "Regular" mfabian@magellan:~$ LC_CTYPE=ta_IN.UTF-8 fc-match "Sans Serif" TSCu_Paranar.ttf: "TSCu_Paranar" "Regular" mfabian@magellan:~$ I.e. for English "Sans Serif" expands to "Verdana" on my machine, for Japanese to "HGPGothicB" and for Tamil to "TSCu_Paranar". In case of these "prefer" lists, the *first* list will win, therefore this is in suse-post-user.conf which is included *after* the user config file ~/.fonts.conf. If the user adds something like <alias> <family>sans-serif</family> <prefer> <family>FreeSans</family> </prefer> </alias> <alias> <family>serif</family> <prefer> <family>FreeSerif</family> </prefer> </alias> <alias> <family>monospace</family> <prefer> <family>FreeMono</family> </prefer> </alias> into his ~/.fonts.conf, these fonts will be selected with higher priority than the fonts listed in suse-post-user.conf. For most other fontconfig rules is is different, the last rule will win. Therefore most fontconfig rules in /etc/fonts are read *before* ~/.fonts.conf to give the user a chance to override it. But for the "prefer" lists it must be read *after* ~/.fonts.conf to give the user a chance to override. Sven> Would the list fail for KDE when Sans-Serif Sven> rather than Verdana is set? No, because "Sans-Serif" expands finally to a font and the the rule to enable the byte code interpreter uses <match target="font">: <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> ... I.e. this is applied to the font finally selected, if "Sans-Serif" expands to "Verdana", this rule will match. Rules which start with <match target="pattern"> work on the pattern used to request a font, rules which start with <match target="font"> work on the final result after the pattern is evaluated and a suitable font has been selected.
Hello! You wrote: Yes, but many users seem to think that the MS-Fonts with anti-aliasing and the autohinter look very good. Although I would not agree, but fair enough, let aa be the default. Yet, as soon as aa is disabled, the majority will think that MS-Fonts look better using bytecode rather than autohinting, or am I wrong? Would it be possible to automatically disable autohinting for the MS-Fonts, if aa is disabled? I am just updating to RC1 which will take a while. I will still have to install the package from comment 15, right? Thanks for the detailed explanations!
Sven> I am just updating to RC1 which will take a while. I will still have to Sven> install the package from comment 15, right? Yes, this is not yet in RC1. Will appear in RC2.
Sven> Yet, as soon as aa is disabled, the majority will think that Sven> MS-Fonts look better using bytecode rather than autohinting, or Sven> am I wrong? Yes, with anti-aliasing off and autohinting on, the MS-Fonts will certainly look worse than with anti-aliasing off and autohinting off. Probably everybody will agree here. Sven> Would it be possible to automatically disable autohinting for Sven> the MS-Fonts, if aa is disabled? Interesting idea. I'll think about it.
Sven> Would it be possible to automatically disable autohinting for Sven> the MS-Fonts, if aa is disabled? Yes, adding the following rule to /etc/fonts/suse-post-user.conf would do it: <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> </test> <test name="antialias"> <bool>false</bool> </test> <edit name="autohint"> <bool>false</bool> </edit> </match> This would switch the autohinter off for the MS-Fonts, if anti-aliasing has been switched off in a config file read earlier. For example, if one switches off anti-aliasing using the KDE control centre for a range from ... point to ... point, the KDE control centre will write a rule setting antialias to false for that range into ~/.fonts.conf. ~/.fonts.conf is read before suse-post-user.conf, therfore suse-post-user.conf can check whether antialias is false *and* the font selected is one of the MS-Fonts or an agfa-font and then also switch off the autohinter. As suse-post-user.conf is read after ~/.fonts.conf, there is no way for a regular user to override this anymore. If a user wants antialias=false *and* autohint=true for the MS-fonts, the only way to achieve that is editing the systemwide config files /etc/fonts, editing ~/.fonts.conf won't help. I.e. only a skilled sysadmin could still change that. But I agree with you that this is not a problem, the MS-fonts clearly look better with the byte code interpreter if antialias=false, I don't expect anybody to disagree here, therefore it is OK to add that rule without being able to override it.
Mike> For example, if one switches off anti-aliasing using the KDE control Mike> centre for a range from ... point to ... point, the KDE control centre Mike> will write a rule setting antialias to false for that range into Mike> ~/.fonts.conf. Not that this currently works only for a range, not if you try to turn of antialiasing unconditionally in the KDE control center, see bug #113637. That is a KDE bug though and as soon as this is fixed the above idea should start to work in that case as well.
I submitted a new fontconfig package with the rule mentioned in comment #21 to /etc/fonts/suse-post-user.conf. Will be in RC2. But you can already test *now* on RC1, you only have to download the updated fontconfig package here: ftp://ftp.suse.com/pub/projects/m17n/10.0/i586/fontconfig-2.3.2.20050721-9.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/i586/fontconfig-devel-2.3.2.20050721-9.i586.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/src/fontconfig-2.3.2.20050721-9.src.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/x86_64/fontconfig-2.3.2.20050721-9.x86_64.rpm ftp://ftp.suse.com/pub/projects/m17n/10.0/x86_64/fontconfig-devel-2.3.2.20050721-9.x86_64.rpm
When I try to install ftp://ftp.suse.com/pub/projects/m17n/10.0/noarch/fonts-config-20041001-8.noarch.rpm I get dependency errors in Yast with RC1, so I could not test that package yet. Yast-output attached. The fontconfig-package from comment 23 works perfectly so far! I just hope that bug 113637 gets fixed before the final realease, this would really make my day! Pin sharp fonts without any re-compiling or editing config-files. Yipeeh!
Created attachment 49486 [details] Conflicts caused by fonts-config package
The dependencey error of YaST is bogus, you can ignore it and install the updated fonts-config package nevertheless. The message says Konflikt mit fonts-config 20041001-8 Konflikt mit: desktop-data-SuSE benötigt /sbin/conf.d/SuSEconfig.fonts Well, as you can see with "rpm -ql fonts-config-20041001-8.noarch.rpm", the package contains "/sbin/conf.d/SuSEconfig.fonts". So I don't know why YaST2 is complaining here. Just choose: ( ) Diesen Konflikt ignorieren und ein inkonsistentes System riskieren
Sven> The fontconfig-package from comment 23 works perfectly so far! I Sven> just hope that bug 113637 gets fixed before the final realease, Sven> this would really make my day! Pin sharp fonts without any Sven> re-compiling or editing config-files. Even if that bug is not fixed, I think it is not a big problem for you because you know now that you can disable anti-aliasing in the KDE control centre from 0 point to some limit and it will work for you. For large sizes, switching anti-aliasing on again clearly looks better. On Microsoft Windows XP, anti-aliasing is on by default for sizes > 18 pixel. It is still a problem for the user who don't know that switching anti-aliasing off in the KDE control centre without giving a range doesn't really switches anti-aliasing off but just uses the system default which may be off or on.
Closing as FIXED.