https://bugzilla.novell.com/show_bug.cgi?id=118131 ------- Comment #93 from mfabian@novell.com 2007-03-23 11:21 MST ------- Sven Burmeister> So is it worth waiting for a fix, or should I simply Sven Burmeister> give up on this and use the workaround from comment Sven Burmeister> #83. I tried this workaround and it helps for the OpenOffice_org from STABLE/Factory but does nothing for the OpenOffice_org which was distributed with openSUSE 10.2. Cor Blom> I've googled a bit around and it seems to me that this bug Cor Blom> report is about two (maybe more) problems. Yes. There are certainly quite a few completely different problems here. Cor Blom> My own problems started with 10.2 (before 10.2 I was Cor Blom> satisfied with my fonts and a far as I could see the Cor Blom> bytecode was used) and are solved by changing Cor Blom> /usr/fonts/suse-hinting.conf as mentioned in comment #83. In 10.2? Did you update the OpenOffice_org packages? I just tested this on 10.2 (antialiasing disabled in OpenOffice) and the workaround made no difference whatsoever. But the workaround helped in STABLE/Factory. I will submit a fontconfig package which uses <!-- Set autohinter=true as the default, then add exceptions for certain fonts: --> <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> </match> instead of <!-- Set autohinter=true as the default, then add exceptions for certain fonts: --> <match target="pattern"> <edit name="autohint"> <bool>true</bool> </edit> </match> which should “fix” the problem for STABLE/Factory. Something is quite unusual in OpenOffice here though, usually a rule like the one above matching on pattern which sets a value is overridden by a rule matching on font. And such a rule, which matches for all TrueType fonts follows in /etc/fonts/suse-hinting.conf just a few lines lower: <!-- Switch off the autohinter for TrueType fonts in order to use the byte code interpreter. --> <match target="font"> <test name="fontformat"> <string>TrueType</string> </test> <edit name="autohint"> <bool>false</bool> </edit> </match> Therefore, in all other programs *except* OpenOffice, autohint is false for all TrueType fonts (except those where autohint is set to true again further below in suse-hinting.conf). Only OpenOffice seems to take the autohint value from "pattern" and then force it when the font is matched. Submitting a fontconfig package with that change is perfectly safe (currently) because there is currently no option to set “autohint” in the Gnome GUI (gnome-font-properties). The reason why I matched on pattern instead on font in that rule was to give Cairo/Gnome a chance to override it. I.e. the same reason why I match on pattern in the rule above in suse-hinting.conf: <!-- Using hinting=true, hintstyle=hintfull and antialias=true 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="hinting"> <bool>true</bool> </edit> <edit name="hintstyle"> <const>hintfull</const> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> Cairo sets these values in pattern and if a rule setting such a value matching on font follows, the Cairo settings are overridden again. But as long as there is no GUI option for autohint in gnome-font-properties, I can just as well always match on font to set the value for autohint. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.