Bug 114949

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.