Bug 118131

Created attachment 50475 [details]
Screenshot showing openoffice UI and document

In fact - what happened to the whole KDE-isation of OO when choosing KDE like we
had it in 9.3 ?

What has KDE-isation to do with this font bug? Please open a new bug report 
for new issues. KDE-isation is offered by the rpm OpenOffice_org-kde that 
should normally be installed when OpenOffice is installed. 

Created attachment 50501 [details]
Same document in OpenOffice 2.0pre build 125 running on SUSE 9.3

Some more information: when starting OpenOffice from within a gnome session, 
the result is about the same as on the first screenshot. 

For the record, attachment 50501 [details] shows the same document in OpenOffice build 
125 on 9.3 where it looks great. 

Created attachment 51138 [details]
Screenshot showing some of the font rendering artifacts

I've also noticed this problem: Under Suse 9.3, everthing looked fine (meaning
that OOo used the same font I set in KDE control center, I just had to change
the scaling a bit), I was using OOo 1.9.125 and 1.9.129. Under Suse 10, the
fonts look corrupted - they're not the same I set in KDE control center. I'm
gonna post a screenshot, seems to me that anti-aliasing isn't working in OOo.

Created attachment 53637 [details]
Fonts are not the same in OOo and Konqueror

Kendy, you already solved some problems with OOo and fonts. Could you look at it?

Note, this is not a common problem. It is specific for your system setting. In the past, OOo had many problems with fonts. It was usually enough to remove one problematic font from the font path and OOo started to work again. However, this might be another problem.

Please, can you attach outputs of the following commands?

ldd /usr/lib/ooo-2.0/program/libvcl680li.so
ldd /opt/kde3/lib/libkdeui.so.4

My suspicion is that you have more 'libfreetype's in your system, and it may create confusion.  By the way, is it a 32bit, or 64bit machine?

Thank you in advance.

Created attachment 54552 [details]
Output of the command "ldd /usr/lib/ooo-2.0/program/libvcl680li.so"

Created attachment 54555 [details]
Output of the command "ldd /opt/kde3/lib/libkdeui.so.4"

See attached files for the output of both commands. My system is a 32bit system (Dell Latitude D800 laptop with a 1680x1050 screen).

Hmm, nothing wrong there :-(

Please, can you please attach a screenshot of your desktop with both a KDE application (e.g. konqueror) and OOo running?

Created attachment 54574 [details]
Requested screenshot of OOO + KDE next to each other

I hope the difference is noticeable on the screenshot. For some reasons, screenshots make it look less "bad". Notice the font artifacts I have circled in the document.

The OOO UI fonts are, among other things, thinner compared to KDE.

I see the difference, thank you!  Apparently OOo and konqueror are using different fonts - I'll try to reporoduce the behaviour here...

No, the fonts are the same; but libfreetype is here the one to blame.

I removed /usr/lib/libfreetype.* and copied there the one from 9.3 - and the fonts are OK (though just slightly different - but that's probably because of the different setting of hinting).  The artefacts disappeared.

I'll also attach a screenshot that shows the worst misrenders that appear with Lucida Sans - see the letter 'r'.

Created attachment 54718 [details]
Misrendering of 'r'

I also noticed that Qt4 does not render the same fonts as KDE applications - both OOo and Qt4 fonts are a lot thinner than in my KDE apps, although they should be using the same fonts "Sans Serif". I hope you can see this in the attached screenshot.

Created attachment 55040 [details]
Wrong fonts in OOo and Qt4

*** Bug 134596 has been marked as a duplicate of this bug. ***

Hi to all who suffer from font rendering problems!

The current affair of things could be boiled down to:
 - freetype2 is missbehaving in several ways:
   - font rendering artifacts as documented there
   - serious kerning issues: see
     https://bugzilla.novell.com/show_bug.cgi?id=133086
 - OOo seems to make things even worse:
   - using certain fonts makes user's eye bleed
   - UI font rendering deviate from system setting (KDE) #134596

I tried to tackle the issue with current cvs freetype2, but besides having a hard time getting it to work, I harvested much nicer looking fonts, but also hard crashes of X :-(.

BTW: it uncovered the IMHO dirtiest part of the current distro, since it uses
patches to export an internal freetype interface as a whole (ft_stream), which seems to be used by fontconfig and Qt. I don't know the history of this mess, but I do understand the freetype people to absolutely detest such moves..

Nothing of this explains the difference of OOo UI font rendering, since it can't be blamed to freetype, as it stands, but it needs to be solved to regain maximum user satisfaction..

So - the last point
     "UI font rendering deviates from system settings".

Whatever you think about that it is a feature (AFAICS etc.). Changing the font hinting / attributes changes the font metrics. The font metrics are a crucial part of the document layout => we just can't change them.

Unfortunately the UI font & the document font share the same rendering infrastructure - so we can't have a different set of hints for the UI over the document. So ...

The above explanation seems right, I noticed that even when using OpenOffice on Windows, font rendering is inferior. On the same system, Office XP does a good job.

However, although the explanation could be correct from a technical point of view, it is rubbish as far as the end-user is concerned. The end-user sees Office XP on Windows XP, rendering all fonts beautifully. Next, that same user sees inferior rendering with OpenOffice. No argument can convince people this is "as it is supposed to be".

I can't confirm that, from my point of view OOo under Windows uses the same nice fonts the whole OS (and also MS Office) uses, so it doesn't look worse.

Moreover, under Suse 9.3 I've also installed the latest 2.0 beta builds, and the font rendering was working perfectly - I had exactly the same font appearance than the rest of my desktop (only the size wasn't correct, I had to scale it down to 99%). The Qt4 applications used to look correctly too.

I also have been using 2.0 beta builds on 9.3 and they looked great. However, that system had a resolution of 1280x1024 at 96dpi. The machine that gives the poor rendering is 1680x1050 at a higher dpi (128).

See screenshots I included as attachment (ages ago).

Under Suse 9.3, it looked perfectly OK on 2 different machines with 1400x1050 and 1280x1024 - under Suse 10.0, OOo and Qt4 fonts are ugly at both resolutions.

I also think that the explanation in comment #25 is right.

On SuSE Linux 10.1 RC1 as well, OpenOffice renders the UI fonts
differently from the system settings. I can see that clearly because I
use subpixel-hinting (colored hinting) as my default settings and
nevertheless OpenOffice renders with gray-scale anti-aliasing (By the
way, this can also be seen in the screen shot in comment #16, coloured
rendering in KDE, gray-scale anti-aliasing in OpenOffice).

The rendering in freetype 2.1.10 has been improved in SuSE Linux 10.1
somewhat over the rendering achieved in SuSE Linux 10.0 (Thanks the
the efforts os Zhe Su and Takashi Iwai).

I hope it renders good enough now.

As comment #25 explains that the difference to the way the rest of the
system renders by default is there for a reason, there is probably
nothing more we can do here.

Therefore I close this bug as WONTFIX.

    When I last looked at this, and we started changing the font
rendering hints to match that of the system - it screwed with the metrics,
and [ depending on what mangled rendering setting you had turned on ], the
document would layout differently.

    At least - that is where I got to last time; now that behavior sounds
(in itself) highly broken, and possibly I was mistaken there; but it is the
predicate that lies behind not having any of this junk turned on. We even still
have the prototype patch here:

    2005-08-15  Michael Meeks  <michael.meeks@novell.com>

    	* patches/test/vcl-font-hinting.diff: add 1st abortive pass
    	at adding desktop-synchronized font hinting to font rendering,
    	problem is - this radically affects layout => potentially
    	breaking/changing the whole document as you switch hinting.

    But it is disabled.

Michael Meeks> and possibly I was mistaken there;

No, I think that is still the case.

For example, if you test with something like

 ftstring -m "Teststring"  10 /usr/X11R6/lib/X11/fonts/truetype/arial.ttf &

and then hit the keys 'h' (hinting on/off) and 'f' (forced auto-hinting on/off),
you can see that the length of "Teststring" changes.

I have the impression that no hinting at all preserves the metric, as soon as
hinting is involved, the metric becomes distorted somewhat.

*** Bug 160802 has been marked as a duplicate of this bug. ***

*** Bug 163990 has been marked as a duplicate of this bug. ***

*** Bug 181788 has been marked as a duplicate of this bug. ***

Why WONTFIX?
See my bug #181788, it also happens on 10.1, and surely looks ugly. It has been marked as duplicated but it's not quite the same bug. For me it works fine and uses the same GNOME font perfectly. But when i change the gnome font, OO fonts gets screwed. It's probably some hinting bug. On my bug i wrongly said it looked not anti-aliased but it IS anti-aliased, so that's why i think it's a hinting problem.

It is rather a CANTFIX. The bug was assigned to me and I certainly have neither
time nor expertise to fix this in OpenOffice.

Thiago> It's probably some hinting bug. On my bug i wrongly said it looked not
Thiago> anti-aliased but it IS anti-aliased, so that's why i think it's a
Thiago> hinting problem.

See comment #32 by Michael Meeks. Yes, it is a hinting
problem. OpenOffices doesn't use the system settings for
hinting. Instead it forcibly switches off hinting altogether. This
avoids metric problems (glyph distances can be changed by hinting) but
makes it look ugly.

I have no idea how to fix this in OpenOffice.

However, it seems that this problem is SUSE specific. Just take a look at OOo in Ubuntu/Kubuntu for example - the fonts match exactly those set globally by the user. So it is not impossible to fix - maybe you could contact the OOo Ubuntu maintainers?

It is really a weak point of SUSE, a lot of people are using OOo, and exactly this program looks different from all other applications. Not a very good impression. It should really be fixed.

Hans - I strongly suspect that the apparent improvement on Ubuntu is simply down to a different choice of default desktop font for your locale / whatever.
Ultimately the differences code-wise in the Ubuntu package can be examined here:

http://go-oo.org/ooo-build/patches/src680/apply

The sub-setting syntax should be quite obvious. The patches are all there, as you can see the Ubuntu build is very similar to ours.

Michael, I only commented on what I've seen from my experience, i.e. running both SUSE 10.1 and Kubuntu 6.06. The problem is not that Kubuntu uses a different default desktop font (which it does, namely DejaVu, but that's not the problem). I've tried the same font with SUSE, but KDE and OOo do not look the same. In Kubuntu, the fonts are absolutely identical.

Please try and see for yourself, just install Kubuntu 6.06 and have a look at KDE and OOo.

Hans: What happens when you save the /usr/lib/libfreetype.* from your SUSE somewhere, and copy there /usr/lib/libfreetype.* from your Ubuntu?  Still the same, or does it get better?

(Of course after OOo restart, etc.)

and running ldconfig before OOo restart and after moving shared libs around..

Ahh, Hans, be prepared to sit in front of a nonworking X after this mod.
SuSE still applies a very ugly patch to freetype (exporting an internal interface, which is used by Qt and fontconfig at least) which most likely isn't available in Kubuntu.

Oh really? Jan, if Hans-Peter is correct, I don't want to try out your suggestion. If SUSE really patches freetype, could this be the reason of all those font problems with OOo?

As I've already said, it works perfectly with Kubuntu. AFAIR it used to work with SUSE 9.3 (or something < 9.3). I don't know about other distros, but if anyone has a comment on that?

Hans-Peter Jansen> SuSE still applies a very ugly patch to freetype
Hans-Peter Jansen> (exporting an internal interface, which is used by
Hans-Peter Jansen> Qt and fontconfig at least)

Which patch?

Hmm, why don't you do it with being on the save side?
E.g. (from a text console, log out from X):
init 3
cd /usr/lib
mkdir xxx
mv libfreetype.so* xxx
cp -a kubuntu/usr/lib/freetype.so* .
ldconfig
init 5
# no X?, restore
rm libfreetype.so*
mv xxx/libfreetype.so* .
rmdir xxx
ldconfig

that's it, 100% destruction free..
It's an easy test for you, while it could give us some important hints.

Hans Meier> Oh really? Jan, if Hans-Peter is correct, I don't want to
Hans Meier> try out your suggestion.

You can easily change it back, Jan wrote in comment #42 that you
should save your /usr/lib/libfreetype.* somewhere.
If you run into trouble, just copy the saved copies back to
the original place.

Hans Meier> If SUSE really patches freetype, could this be the reason
Hans Meier> of all those font problems with OOo?

No. Of course that patches we apply to freetype2 have an effect on the
rendering. But that affects the whole system, not only OpenOffice.
That the fonts in OpenOffice look different from the fonts in the rest
of the system is because OpenOffice uses different hinting settings.

Reassign to Michael Meeks because I think this problem is neither 
caused by freetype2 nor fontconfig.

Mike Fabian> Which patch?

It's called ft2-stream-compat.diff, exporting the internal ft2-stream interface. 

I innocently mentioned this on the freetype ML, and harvested just bashing. :-(

Okay, I investigated this a bit more, and it boils down to:
 - with the next (2.2.1) version of freetype, many users of freetype
   internals are expected to get fixed. See:
http://www.freetype.org/freetype2/patches/rogue-patches.html

For those, who want to investigate this even further, here are a few pointers.
I would go and build a new freetype package:
- Apply SuSE patches
- Try to apply the active (as noted in debian/rules) ubuntu patches (ignore
  already applied changes, and check the rejects)

The current ubuntu freetype patch is available here:
http://security.ubuntu.com/ubuntu/pool/main/f/freetype/freetype_2.1.10-1ubuntu2.1.diff.gz

I would do it myself, but I haven't installed 10.1 yet, (and should have done something different today..). 

@Mike: Do you care the security fixes mentioned in there?
They also have some quite interesting looking patches, like:
freetype-2.1.10/debian/patches/freetype-2.1.10-fixkerning.patch
freetype-2.1.10/debian/patches/050-autohint-rounding.diff
freetype-2.1.10/debian/patches/090-freetype-2.1.7-normalize-fix.diff
which don't exist in the SuSE package, as noted those from a cursory look.

Funny enough, they use a fix similar to mine, as noted in
https://bugzilla.novell.com/show_bug.cgi?id=133086. Hmmm.

I've tried and replaced all libfreetype* from Suse with the ones from Ubuntu. However, the fonts in OOo looked the same as before. BTW, the fonts do not look bad and they are rendered correctly, only the sizes do not match. When setting the scale to 100% in OOo, the font is much bigger than the default KDE fonts. When setting it to 99%, the character sizes are about the same (but not identical), but the spacing between the characters is larger than in KDE.

*** Bug 223591 has been marked as a duplicate of this bug. ***

*** Bug 217704 has been marked as a duplicate of this bug. ***

Regarding comment #25. In OO's settings there is a setting "use systen fonts". What does that one change?

In 10.0 and 10.1 for me it changed the fonts used for GUI from unacceptable to as cleanly rendered as TrueType fonts like Arial are by the bytecode-interpreter.

If as clean fonts (without aa) were possible in 10.1 why should they not be possible in 10.2 anymore?

Since bug 217704 is still considered a duplicate, I'll answer here.

First, those that think that this is not regression (for 10.2) or think that it is a feature and a "cantfix", please have a look at the screenshot which was made on 10.1: https://bugzilla.novell.com/attachment.cgi?id=108809&action=view

What you see is that in 10.1 there were crystal clear fonts in KDE and OO's GUI as well as text, no aa, no artifacts. Hence there is no denying that this is possible and did work perfectly before. OO or whatever causes this bug just has to work the way it did in 10.1.

I wonder how OO could achieve these perfectly rendered Truetype fonts in 10.1, if not by using bytecode, but I am no developer, so it might well be that OO has a rendering infrastructure as good as bytecode in order to render the fonts. However, if it used the bytecode, then it stopped doing it due to whatever reason in 10.2. The latter is also the reason why this bug is not the same as bug 217704 since this one started with 9.3 and 217704 with 10.2.

For me, using Truetype fonts without bytecode compiled into freetype2 resulted in the unacceptable font-display (SuSE 9.3) that can be seen on all those screenshots. After re-compiling freetype2 from the source-rpms provided by SuSE, they were fine.

Since 10.0(?) bytecode is enabled by default in freetype2, so there was no need to re-compile it, it just worked out of the box. Thanks to /etc/fonts/suse-hinting.conf bytecode is/was used for the TrueType fonts, even by OO as it seems, yet not any longer.

Since this worked in 10.1 and it does not in 10.2 it does not matter why, how or when, something caused this change in appearance and hence it is a bug and it should be reverted/fixed.

It is just de-motivating, if one reports an obvious bug, backs it with screenshots plus other people posting that they experience the same but one still has to spent post after post just to make sure that it does not get marked as invalid, enhancement or minor. This bug here is not even assigned, it's severity is considered "normal" and has "none" as priority. If bug 217704 was not considered a duplicate, i.e. the same bug, fair enough, but since you insist...

The broken font-rendering is not a feature, it is not minor and it is not invalid or "cantfix". It does not matter whether it is an OO bug, i.e. it no longer using the bytecode-interpreter for Truetype-fonts, a KDE bug or a xyz bug, it is a bug that did not exist in 10.1 and should be fixed ASAP in 10.2. I wonder how this could get through QA?

Created attachment 109009 [details]
OpenOffice ugly font rendering

Created attachment 109010 [details]
OpenOffice pretty font rendering

A possible solution, that works for me.

take usr/lib/libXft.so.2.1.2 from
http://packages.debian.org/testing/libs/libxft2

take usr/lib/libfreetype.so.6.3.5 from
http://packages.debian.org/stable/libs/libfreetype6

and put them in /usr/lib/ooo-2.0/program

then change /usr/lib/ooo-2.0/program/soffice line #252 to read like
env LD_PRELOAD=/usr/lib/ooo-2.0/program/libfreetype.so.6.3.5:/usr/lib/ooo-2.0/program/libXft.so.2.1.2 "$sd_prog/$sd_binary" "$@" &

that is prepend
env LD_PRELOAD=/usr/lib/ooo-2.0/program/libfreetype.so.6.3.5:/usr/lib/ooo-2.0/program/libXft.so.2.1.2
to the already existing "$sd_prog/$sd_binary" "$@" &

this is a trick that i apply to debian 4.0 (currently testing).
Of course when in debian i don't have to bother with libXft, but opensuse gave me a
symbol lookup error: /usr/lib/libXft.so.2: undefined symbol: FT_Library_SetLcdFilter
when i ignored it.

My conclusion is that opensuse 10.2 has been patched in order to play nicely  with the new proper design of libfreetype which hides internal details (not of out business anyway). OpenOffice has yet to face that issue, so opensuse developers removed the patches that made OpenOffice play with systems freetype and reverted back to linking OpenOffice statically with the included freetype library.

Apart from trick i can see only to ways to proper resolv that issue. Either  to wait OpenOffice to work with the newer version of freetype, or to patch the included freetype to use BYTECODE.

ps. It is my understanding that if i preload a library including part of the symbols found in a binary, then while executing the binary library's functions will be preferred over builtins, and that's how the all thing with preload is working.

ps2. the new version of freetype i mentioned before is 2.2.2, not released yet, but i think freetype2-2.2.1.20061027-11 refers to a development snapshot of 2.2.2

attached to images to demonstrate my understudying of the issue
https://bugzilla.novell.com/attachment.cgi?id=109009
https://bugzilla.novell.com/attachment.cgi?id=109010

or even better

take usr/lib/libfreetype.so.6.3.8 from
http://download.opensuse.org/distribution/SL-10.1/inst-source/suse/i586/freetype2-2.1.10-16.i586.rpm

and usr/X11R6/lib/libXft.2.1.2 from
http://download.opensuse.org/distribution/SL-10.1/inst-source/suse/i586/xorg-x11-libs-6.9.0-48.i586.rpm

and prepend

env
LD_PRELOAD=/usr/lib/ooo-2.0/program/libfreetype.so.6.3.8:/usr/lib/ooo-2.0/program/libXft.so.2.1.2
to "$sd_prog/$sd_binary" "$@" &

since using the previous compination i came up with a symbol lookup error: /usr/lib/ooo-2.0/program/libvcl680li.so: undefined symbol: FT_GlyphSlot_Embolden

Hi Mike,

I just noticed that Rene added the patch from http://qa.openoffice.org/issues/show_bug.cgi?id=64508 to ooo-build HEAD a week ago; would be probably worth re-testing when the package (OOo 2.1) gets to STABLE...

Using the 2.1 RPMs from openoffice.org works, i.e. renders the fonts as in 10.1.

Unfortunately there are no packages at ftp://ftp.suse.com/pub/projects/OpenOffice.org/10.2-i386 yet. There are just 2.0.4 packages which I have not tried yet. The latter have a lower build number according to Yast, so I wonder if they are worth a try.

Sven: No, the 2.0.4's don't have that patch in.  The 2.1 upstream packages don't prove much I'm afraid, because they pack their own freetype.

Petr: Please, are there 2.1 packages around for Sven to test?

I have upload the recent recent 2.1 packages at
ftp://ftp.suse.com/pub/projects/OpenOffice.org/10.2-i386/2.1-0.1

Thanks for the effort! I installed the packages and they suffer the same issue as opposed to the 2.1 packages from www.openoffice.org.

So does this mean that it is not an OO but Novell bug?

Sven: Well, kind of ;-)

Please, could you try another thing?  Close all OOo's, find libfreetype.so.6 in the installation of the OOo from www.openoffice.org, copy it to /usr/lib/ooo-2.0/program/ and start (Novell) OOo again.

If it crashes, the libfreetype is binary incompatible, and it tells nothing; but if it starts working, that would be interesting - that would mean that the bug is in our libfreetype.

libfreetype is in the openoffice.org-core10-2.1.0-6.i586.rpm package and should be placed in /opt/openoffice.org2.1/program/filter/libfreetype.so.6. I copied it to /usr/lib/ooo-2.0/program/ and OO segfaults:

pc192s:/usr/lib/ooo-2.1/program # oowriter
/usr/lib/ooo-2.1/program/soffice.bin: symbol lookup error: /usr/lib/libXft.so.2: undefined symbol: FT_Library_SetLcdFilter

** (process:32590): WARNING **: Unknown error forking main binary / abnormal early exit ...

Installing the freetype packages from factory did not help either.

Kendy - AFAIR you were looking at this sort of font issue in another bug ?

Even factory is way behind ATM.

Guys, you should consider testing with freetype-2.3.1. They've fixed a few ugly bugs lately. It's quite easy to build it based on freetype2 from 10.2 or factory. 

Just install some freetype2-*.src.rpm with rpm -i, copy version 2.3.1 including doc from http://download.savannah.gnu.org/releases/freetype into /usr/src/packages/SOURCES, cp attached spec file to /usr/src/packages/SPECS, 
run:
rpmbuild -ba --target \ 
  i686-suse-linux /usr/src/packages/SPECS/freetype2-2.3.1.spec

é voila, your brand new SUSE compatible freetype2 package is ready to be installed on any number of machines.. I'm using it on 9.3 with success. 

I just switched off "using system font" in OO, since that looked too ugly with Tahoma.., and accepted the AA-blurriness on font rendering here.

Let us know about the outcome.

Created attachment 117344 [details]
freetype 2.3.1 spec file

Is there any reason not to update factory to the latest version of freetype or shall I just ask the maintainer?

Well, it was released 5 days ago, and since it's a critical system package, the maintainer is very careful in this respect, I guess, but since Mike subscribed to this bug today, he may answer this himself. 

Also note, that freetype2 needs lots of non trivial testing on largely varying systems, and the outcome is also a matter of taste of course. 

A first step would be, that some people around here, who really care about these issues, test it right know, and call back with the results. 

That will give the maintainers more data points to make the "right" decision.

Ok, if factory is too stable for this purpose, please provide a package somewhere else, be it the build-service or any suse-dev's personal directory. That way the package is guaranteed to be build correctly.

Although I think that I could successfully compile the package, I would not be sure if it was exactly the package suse would provide, regarding patches etc.

> Ok, if factory is too stable for this purpose, please provide a package
> somewhere else, be it the build-service or any suse-dev's personal
> directory.

This is planned, but I'm very time contrained in the moment - sorry.

> That way the package is guaranteed to be build correctly.
>
> Although I think that I could successfully compile the package, I would not
> be sure if it was exactly the package suse would provide, regarding patches
> etc.

That's why I outlined the steps above - just to make sure, the necessary patches are available. Those patches, which are disabled in the spec simply are those which are already applied upstream, but #3 is still missing (somebody may ask freetype project people to apply it), and #4 is a hack to export the internal stream interface, which still seems to be necessary for SUSE, but don't try to ask them to apply that one, since they're on a crusade to exterminate the usage of this internal interface since quite a while. 
Been there, done that, got a lot of bashing for just innocently asking :-(..
#100/#200 are simple option switchers concerning the bytecode interpreter, and subpixel rendering. They should match those in the distribution (AFAICT, they're enabled since 10.0). The result should be 100% identical with those from the build service. A small deviation is, that I'm building for i686 by default, just use "--target i586-suse-linux" if you have concerns in this respect. When using the same compile version, you should get 100% identical binaries (as long as you haven't played any gcc, binutils, or glibc games on your system).

Ah, a minor issue: in the official package, the docs get preprocessed in order to get rid of the build time dependency on python. For us, this doesn't matter, since I bet, you have python installed anyway already..

Any other difference is in the code itself, and that's what should get tested..

freetype 2.3.1 is in Factory now and also in
http://software.opensuse.org/download/M17N/ for older releases
(may take some time until the build service has everything built).

Hans-Peter Jansen>  #4 is a hack to export the internal stream
Hans-Peter Jansen> interface, which still seems to be necessary for
Hans-Peter Jansen> SUSE

From the freetype2.changes file:

-------------------------------------------------------------------
Wed Mar 24 01:14:22 CET 2004 - mfabian@suse.de

- Add ft2-stream-compat.diff for binary compatibility when
  upgrading from SLES8 to SLES9.
  The FT_Stream functions have been renamed and although these
  functions were declared for internal use only by the freetype
  developers, they have been used in Qt (and possibly elsewhere).
  Therefore, 3rd party which linked statically against Qt might
  not work after upgrading from SLES8 to SLES9.
  Fix this problem with a patch by Kurt Garloff <garloff@suse.de>
  which defines appropriate weak symbols. 

-------------------------------------------------------------------

I.e. the patch in question is only a backwards compatibility hack
for bad applications which stupidly used internal freetype interfaces.
It was still necessary on SLES9. But most likely it isn't necessary
on SuSE Linux >= 10.0 anymore.

As I cannot recommend to use freetype 2.3.1 on SLES9
(many strange things will happen), I think I will remove that
patch soon.

Mike Fabian> freetype 2.3.1 is in Factory now and also in
Mike Fabian> http://software.opensuse.org/download/M17N/ for older releases
Mike Fabian> (may take some time until the build service has everything 
Mike Fabian> built).

Now that was quick - thanks a lot. Hopefully it does well for everybody..

Guys and gals, please test this package now!

Mike Fabian> As I cannot recommend to use freetype 2.3.1 on SLES9
Mike Fabian> (many strange things will happen), I think I will remove that
Mike Fabian> patch soon.

That sounds like a sane decision, and now seems the right time. Here is the freetype developers list of the usual offenders:

http://www.freetype.org/freetype2/patches/rogue-patches.html

You may %ifdef its application to not break in the older releases.

What about patch #3? I don't understand neither freetype nor pcf fonts well enough do describe what the patch is for, what consequences it has (other than mangling the font name) and who's the orginator, but it looks interesting enough.

OO still seems to not use bytecode for ttf.

Is it possible to find out which freetype-version OO puts into its RPMs? If the latter version does not work, freetype would not seem to be the problem.

Sven: Up-stream uses 2.2.1 with #if 0'ed  FT_USE_MODULE(winfnt_driver_class), FT_USE_MODULE(pcf_driver_class) and FT_USE_MODULE(bdf_driver_class) in include/freetype/config/ftmodule.h [not sure if that's relevant for this bug, but...]

Hans-Peter Jansen> What about patch #3? I don't understand neither
Hans-Peter Jansen> freetype nor pcf fonts well enough do describe what
Hans-Peter Jansen> the patch is for, what consequences it has (other
Hans-Peter Jansen> than mangling the font name) and who's the
Hans-Peter Jansen> orginator, but it looks interesting enough.

That patch is necessary to distinguish between fonts
like "Misc Fixed", "Sony Fixed", "ETL Fixed", ...

Without that patch, all these would show up only as "Fixed" in font
selection dialogs. This is very confusing and you cannot select some
fonts at all then. For example if you use konsole and select the
custom "Fixed" and then change the size you may get a "Misc Fixed"
font at some size and a "Sony Fixed" at another size and you will
wonder why the font style changes so drastically just by changing the
size by one pixel. And you may not be able to select "Foo Fixed" at
all because "Bar Fixed" happens to be used if both are just called
"Fixed".

This patch has another useful benefit. The Adobe bitmap fonts from
Xorg are called "Adobe Helvetica", "Adobe Times", and "Adobe Courier"
with this patch instead of just "Helvetica", "Times", and "Courier".
Many web pages specify "Helvetica", "Times", and "Courier" and if the
names of the bitmap fonts are exactly like that, most browsers will
use the bitmap fonts. This is usually not what one wants, the pages
will then show weird mixtures of bitmap fonts with antialiased fonts.
Of course one could disable these bitmap fonts in fontconfig
completely.  But I think it is nicer to still have them available with
the "Adobe *" names than to disable them completely.  If there is no
"Helvetica", a fallback like "Arial" or "Nimbus Sans L" will be used
which is much better than using these old bitmap fonts.

I made this patch originally. I discussed it upstream on the freetype
mailing list. First, the freetype developers liked it and wanted to
include it. Then somebody said that that one shouldn't put the foundry
name into the font name. But there are many fonts doing that, for
example "Bitstream Vera Sans" or "Arial Unicode MS" (the latter has
the foundry even at the end, i.e. it is not done in a consistant way
at all by the font makers). It was suggested that all the font dialogs
should be changed to be able to display and select the foundry as well.
But this is not easy either. It will take a long time to change all
KDE, Gnome, OpenOffice, Firefox, whatever, ... font dialogs like that.
Currently none of them lets you select the foundry, only the family.
And if many completely different fonts have the same family name you
cannot select the fonts you want anymore. On top of that, trying
to get more options into dialogs often meets resistance by the GUI
designers: "We don't want to many options, nobody understands that".
I think that is silly, one should not treat users as stupid.

Anyway, prepending the foundry name to the family name for the bitmap
fonts solved that problem at hand. It is a pragmatic solution, but it
works well.

I should try to discuss this again upstream, the last time the
discussion was completely sidetracked, the thread became very long and
at the end it led nowhere.

*** Bug 243260 has been marked as a duplicate of this bug. ***

(In reply to comment #62)
> I just noticed that Rene added the patch from
> http://qa.openoffice.org/issues/show_bug.cgi?id=64508 to ooo-build HEAD a week
> ago; would be probably worth re-testing when the package (OOo 2.1) gets to
> STABLE...
> 
The original patch has been changed in ooo-build (quote from webcvs):

Revision 8325 - (view) (download) - [select for diffs] 
 Modified Fri Dec 8 03:02:01 2006 UTC (2 months ago) by jiaojh 
File length: 36773 byte(s) 
Diff to previous 8293 
Modify FcConfigSubstitute's third patameter to FcMatchPattern to make FcPatternGetBool
get FC_EMBEDDED_BITMAP correctly.

"FcMatchPattern" was "FcMatchFont". I'm no programmer, but suse-hinting.conf has the following lines:

<!--
    Set autohinter=true as the default, then add exceptions for certain fonts:
-->

        <match target="pattern">
                <edit name="autohint">
                        <bool>true</bool>
                </edit>
        </match>

Can it be that this "pattern" is read by OO.o 2.1 and that it ignores <match target "font"> stuff in suse-hinting.conf and that it always uses the autohinter? When I change this setting to "false", I get nice fonts in OO.o. (btw. I haven't updated freetype).

Urgh; so - it seems that a Fedora patch slipped into ooo-build in recent times that in fact enables font hinting based on the fontconfig settings for that font:
ooo64508.vcl.honourfontconfighinting.diff

I guess we need to review whether the effect on metrics is significant enough with this and/or what to do about it if so, and potentially disable that if it's bad enough.

Are there any packages to test without the "fix" mentioned in comment 84.

Is there a suse-hinting.conf to test which is updated to OOs current needs and resolving the FcMatchPattern/FcMatchFont issue?

Since there will be a need to provide a new OO anyway via YOU, could this issue here please be fixed as well? And before that, in order to make sure it really is fixed some packages without the Fedora-patch?

http://www.debian.org/security/2007/dsa-1270 is why I think there will be a need for an update anyway.

Michael Meeks> Urgh; so - it seems that a Fedora patch slipped into
Michael Meeks> ooo-build in recent times that in fact enables font
Michael Meeks> hinting based on the fontconfig settings for that font:

Michael Meeks> ooo64508.vcl.honourfontconfighinting.diff

Whatever this patch does, it cannot be the culprit for most of the problems
we were suffering in this bug and related bugs like bug #217704 for example.

When I last worked on bug #217704 to find out why the byte code
interpreter is not used in OpenOffice when antialiasing is off (This
was arwhen I wrote comment #33 in bug #217704, i.e. 2006-12-08), this
patch was not yet included.

I still have the checkout of the OpenOffice_org package from that
time on my local disk and it doesn't have that patch.

So is it worth waiting for a fix, or should I simply give up on this and use the workaround from comment #83.

I've googled a bit around and it seems to me that this bug report is about two (maybe more) problems. My own problems started with 10.2 (before 10.2 I was satisfied with my fonts and a far as I could see the bytecode was used) and are solved by changing /usr/fonts/suse-hinting.conf as mentioned in comment #83.

According to this mail

http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=17880

something changed with freetype 2.2 wrt the way light hinting is handled. Light hinting is used by OpenOffice_org. This is solved by the fedora patch, because then the hinting as specified by fontconfig is used (in my case full hinting). The freetype from 10.2 doesn't use the bytecode with light hinting, but is does use it with the medium and full.

So the problem before and after the inclusion of the fedora patch is different.

By the way: is this bugreport from debian not about the same problem?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385798

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.

Cor Blom> something changed with freetype 2.2 wrt the way light
Cor Blom> hinting is handled. Light hinting is used by
Cor Blom> OpenOffice_org. This is solved by the fedora patch, because
Cor Blom> then the hinting as specified by fontconfig is used (in my
Cor Blom> case full hinting).  The freetype from 10.2 doesn't use the
Cor Blom> bytecode with light hinting, but is does use it with the
Cor Blom> medium and full.

Yes, recent versions of freetype force use of the autohinter
when hintstyle=hintlight. David Turner wrote a mail on a freetype mailing
list explaining that this is on purpose.

(In reply to comment #93)
> In 10.2? Did you update the OpenOffice_org packages?
> 
I use updated OpenOffice_org packages, now in the BuildService. I had problems with the 2.0.4 from 10.2. As far as I understand it, the fontconfig patch is the difference.

I.e. you have OpenOffice_org 2.1 packages from the build service now?

(In reply to comment #96)
> I.e. you have OpenOffice_org 2.1 packages from the build service now?
> 
yes

It certainly does work for me with the packages from ftp://ftp.suse.com/pub/projects/OpenOffice.org/10.2-i386/2.1-0.1 and editing /etc/fonts/suse-hinting.conf. Yet something resets that value, I think it is SuSEconfig.

I get bytecode-rendered fonts without aa for both UI and text.

Sven Burmeister> It certainly does work for me with the packages from
Sven Burmeister> ftp://ftp.suse.com/pub/projects/OpenOffice.org/10.2-i386/2.1-0.1
Sven Burmeister> and editing /etc/fonts/suse-hinting.conf. Yet
Sven Burmeister> something resets that value, I think it is
Sven Burmeister> SuSEconfig.

Yes, the comment at the top of /etc/fonts/suse-hinting.conf warns you that this
is overwritten by SuSEconfig and that you should put your changes into ~/.fonts.conf.

I.e. you can put

 <match target="pattern" >
  <edit mode="assign" name="autohint" >
   <bool>false</bool>
  </edit>
 </match>


into ~/.fonts.conf to get this for one user.

To get the change for all users you could create a file /etc/fonts/local.conf
and put the change there (see /etc/fonts/conf.d/55-local.conf).

The template used by SuSEconfig to overwrite /etc/fonts/suse-hinting.conf
comes from the package “fonts-config” 
(/usr/share/fonts-config/suse-hinting.conf.template). You could also
edit that template to get the change system wide.

But just wait a few hours and get the updated “fontconfig”and 
“fonts-config” packages from

http://software.opensuse.org/download/M17N/openSUSE_10.2/

I've already submitted updated “fontconfig” and “fonts-config”
packages to STABLE and the openSUSE build service.  They will be
available under the above URL as soon as the build service has
finished building them which seems to be a bit slow at the moment.
Might take some more hours. 

Sven Burmeister> I get bytecode-rendered fonts without aa for both UI and text.

Yes, and also with aa the byte code interpreter is used.

I still think that it is a bug in OpenOffice to take the autohint
value from “pattern” if it is there and enforce it even if a rule
matching on “font” tries to override this. I don't think any other
program does something like this. OpenOffice should not fiddle with
the hinting settings in such mysterious ways, if at all possible the
system settings should be used just like all the other programs do.

Of course then one may run into problems because of the distortion of
the metric caused by the hinting. But there must be other ways to
solve this.

*And*, the metrics are distorted mainly when the autohinter is used.
When the autohinter is used lenghts of strings change significantly
when comparing rendering with and without hinting.

It appears to me that when the byte code interpreter is used the
lengths of strings don't change significantly when comparing rendering
with and without hinting. I.e. the byte code interpreter distorts the
metrics far less than the autohinter does.  Possibly there is no
distortion at all.

I installed:
fontconfig-2.4.2-18.1.i586.rpm
fonts-config-20061025-21.1.noarch.rpm

and it seems to work.

Mike Fabian> It appears to me that when the byte code interpreter is
Mike Fabian> used the lengths of strings don't change significantly
Mike Fabian> when comparing rendering with and without
Mike Fabian> hinting. I.e. the byte code interpreter distorts the
Mike Fabian> metrics far less than the autohinter does.  Possibly
Mike Fabian> there is no distortion at all.

It's not true that there is no distortion at all: with the byte code
the lengths of strings may also change a little bit when the hinting
is switched on or off. But this effect is usually a lot smaller
than with the autohinter. I've not yet seen distortions as bad
as those in bug #215602 with the byte code interpreter.

Sven Burmeister> I installed:
Sven Burmeister> fontconfig-2.4.2-18.1.i586.rpm
Sven Burmeister> fonts-config-20061025-21.1.noarch.rpm
Sven Burmeister> 
Sven Burmeister> and it seems to work.

I think we can close this bug as fixed then because it works after
updating to the above packages and to OpenOffice_org 2.1.  I.e. we
have a solution/workaround.

But I think that in the long run OpenOffice should be fixed to leave
the hinting settings alone.

Closing as FIXED.

Will those packages be available via YOU? Or do they only work with 2.1 anyway?

Sven Burmeister> Will those packages be available via YOU?

I'm not sure whether this makes sense or not.

Sven Burmeister> Or do they only work with 2.1 anyway?

Yes, they work *only* with 2.1. There is no effect whatsoever with the
OpenOffice_org 2.0.4 originally distributed with openSUSE 10.2.

And I am worried what might happen with the next release of
OpenOffice_org. If OpenOffice keeps fiddling with the hinting
settings, I am afraid that problems will pop up again.

I changed the default fontconfig setup only to workaround this special
problem of OpenOffice_org, I know of no other applications which needs
that. 

If I have a certain setup in fontconfig, I expect it to be used.
Other applications use the fontconfig setup as intended, i.e.  the
user can know what change in the fontconfig setup achieves what.  But
when OpenOffice ignores it and overrides it in such unpredictable ways
which may even change with each release, how is the user supposed
to understand what happens and what changes in the fontconfig setup
have what effect?

> If I have a certain setup in fontconfig, I expect it to be used.
> Other applications use the fontconfig setup as intended, i.e.  the
> user can know what change in the fontconfig setup achieves what.  But
> when OpenOffice ignores it and overrides it in such unpredictable ways
> which may even change with each release, how is the user supposed
> to understand what happens and what changes in the fontconfig setup
> have what effect?

Does Novell not pay some OO-devs amd is big enough anyway to knock on OO's door and demand some consistency. The case seems to be clear enough and I would consider it a bug, yet OO's bug-tracker has an sutomatism to mark bugs as enhancement, so who knows. ;)

If OpenOffice is using fontconfig in the wrong way, isn't the right solution to
change this. In comment #83 I referred to a change in the patch responsible for
the fontconfigsetting in OpenOffice. If I understand the change correctly, this
change is responsible for the fact that OpenOffice is using the _pattern_
seeting in fontconfig. The original patch from fedora and the patch in this
bugreport:

http://qa.openoffice.org/issues/show_bug.cgi?id=64508

is using the _font_ setting. It seems to me there is an easy solution: change
the patch back to the original one and then it is working as it should. Or am I
missing something here?

Is that patch in 2.0.4 which comes with openSuSE 10.2? Because 2.0.4 has this bug too and if it was caused by the patch it should not have it.

Which patch are you talking about?

The one from comment 83 mentioned in comment 106.

Although this bug has the status resolved, I still want to add 2 comments. 

Comment 1: I have installed the patches mentioned above.  (fontconfig-2.4.2-18.1.i586.rpm and fonts-config-20061025-21.1.noarch.rpm). 
Still, the fonts in Openoffice menus do not (!) look like the fonts in KDE.

I have set the OO options to use system fonts and activated antialiasing both in OO and KDE. The fonts in OO and KDE look similar but no equal -  and  the smoothing quality is remarkably better in KDE applications. (From the discussion above I got the impression that this is different in Ubuntu. There the fonts in OO and in desktop applications look the same. See comment #39). I therefore cannot say that the goal of getting an equal representation of system fonts in OO as in KDE has been reached. So the only advantage of the workaround is that now the fonts are much better rendered when antialiasing is disabled in OO. The quality with OO version 2.2.1-43.1 is now exactly the same as I had it before with OO 2.0.4 in SUSE 10.1 and in my original unmodified SUSE 10.2 installation. 
 
Comment 2: I additionally installed the freetype2 package 2.3.5-8.1 from the Opensuse M17N repo. Regarding font rendering and display in OO the new version of freetype2 2.3.5 did not improve anything, unfortunately. (If I understood the discussion above correctly  this was to be expected ). 

Another thing that hit me is that the color subpixel hinting is completely activated in KDE again after the installation of the M17N freetype2 package. I wondered why this was the case as SuSE normally does not deliver it like that anymore. As a test, I then recompiled the source code package with the following command "rpmbuild --rebuild --target x86_64 --with subpixel freetype2-2.3.5-8.1.src.rpm" and installed the resulting package. Then the options for subpixel-hinting were again different in KDE -> only the "hinting style" can be changed, but the subpixel-hinting option itself is not changeable. (Just as in my original unmodified Opensuse 10.2 installation). Strange! 

Another remarkable point is that one cannot reproduce the nice antialiasing the original SuSE freetype2-2.2.1 rpm delivered (with supixel-hinting only partially enabled) with the M17N freetype2-2.3.5 package and (!) with full color subpixel hinting enabled. 
Black letters on white background get  slightly colored edges on my system (Samsung 244T TFT, Nvidia 7800 GTX card) with RGB or BGR subpixel hinting activated.  
However, with SuSE's 2.2.1 freetype2 package where the subpixel hinting is only partially disabled (only the hinting style can be changed) the smoothing of the letters appears to be done with gray shading and not with colors - resulting in a much better font representation on the KDE screen.
Can someone elaborate on the differences? What exactly is activated in SuSE's freetype2 packages where you cannot change the subpixel option itself, but only the "hinting style"? (Changes in the hinting style produce different results, so in a way subpixel hinting does not seem to be completely inactive in version 2.2.1, but somehow reduced to smoothing with grey colors).    
       

Ralph Moenchmeyer> Another thing that hit me is that the color subpixel hinting is completely
Ralph Moenchmeyer> activated in KDE again after the installation of the M17N freetype2 package. I
Ralph Moenchmeyer> wondered why this was the case as SuSE normally does not deliver it like that
Ralph Moenchmeyer> anymore.

There are possible patent problems with enabling the subpixel hinting.
Therefore, we don't put freetype packages with subpixel hinting enabled in any official
products anymore.

But the packages in the M17N repository are just experimental, therefore I enabled
the subpixel hinting in these packages to make it easy for me (and users) to test
what difference enabling subpixel hinting would make. There may also be users
who are not affected by the subpixel hinting patents, they can easily get a
freetype2 package with subpixel hinting enabled from the M17N repository.

Ralph Moenchmeyer> As a test, I then recompiled the source code package with the
Ralph Moenchmeyer> following command "rpmbuild --rebuild --target x86_64 --with subpixel
Ralph Moenchmeyer> freetype2-2.3.5-8.1.src.rpm" and installed the resulting package. Then the
Ralph Moenchmeyer> options for subpixel-hinting were again different in KDE -> only the "hinting
Ralph Moenchmeyer> style" can be changed, but the subpixel-hinting option itself is not
Ralph Moenchmeyer> changeable. (Just as in my original unmodified Opensuse 10.2 installation).
Ralph Moenchmeyer> Strange! 

Your build didn't enable the subpixel hinting because the rpm macro used in freetype2.spec
looks like this:

    %define enable_subpixel_rendering 0%{?opensuse_bs}

(off in a regular SuSE build, on in the openSUSE build service).

Ralph Moenchmeyer> Another remarkable point is that one cannot reproduce the nice antialiasing the
Ralph Moenchmeyer> original SuSE freetype2-2.2.1 rpm delivered (with supixel-hinting only
Ralph Moenchmeyer> partially enabled)

Why do you think it was only partially enabled? Subpixel hinting was always enabled
in freetype2-2.2.1 and there was no easy way to turn it off when compiling freetype2.

In freetype2-2.2.2.20061027 as delivered with openSUSE 10.2, subpixel hinting was already
completely disabled during compile.

Ralph Moenchmeyer> with the M17N freetype2-2.3.5 package and (!) with full
Ralph Moenchmeyer> color subpixel hinting enabled. 
Ralph Moenchmeyer> Black letters on white background get  slightly colored edges on my system
Ralph Moenchmeyer> (Samsung 244T TFT, Nvidia 7800 GTX card) with RGB or BGR subpixel hinting
Ralph Moenchmeyer> activated.

Ralph Moenchmeyer> However, with SuSE's 2.2.1 freetype2 package where the subpixel hinting is only
Ralph Moenchmeyer> partially disabled (only the hinting style can be changed) the smoothing of the
Ralph Moenchmeyer> letters appears to be done with gray shading and not with colors - resulting in
Ralph Moenchmeyer> a much better font representation on the KDE screen.

I still don't understand what you mean by “partially disabled”.

Do you mean that you cannot switch on subpixel hinting in the KDE control centre, even if
you have a freetype2 package installed which has subpixel hinting enabled?

Ralph Moenchmeyer> Can someone elaborate on the differences? What exactly is activated in SuSE's
Ralph Moenchmeyer> freetype2 packages where you cannot change the subpixel option itself, but only
Ralph Moenchmeyer> the "hinting style"? (Changes in the hinting style produce different results,
Ralph Moenchmeyer> so in a way subpixel hinting does not seem to be completely inactive in version
Ralph Moenchmeyer> 2.2.1, but somehow reduced to smoothing with grey colors).    

It seems that in recent openSUSE KDE packages, the dialog to switch on subpixel hinting in the
KDE control centre is gone. Probably because of the possible patent problems.

Nevertheless you can switch on subpixel hinting manually by adding

     <match target="font" >
      <edit mode="assign" name="rgba" >
       <const>rgb</const>
      </edit>
     </match>

to your ~/.fonts.conf file.

If you have a freetype2 package installed, which has subpixel hinting not compiled in,
this will have no effect you will still get grayscale rendering, exactly
the same way as if you had chosen the value "none" instead of "rgb".

But if you have a freetype2 package installed with subpixel hinting compiled in,
this option in ~/.fonts.conf will switch it on, just like the dialog in the KDE
control centre did (This dialog did just save the above lines to ~/.fonts.conf).

Created attachment 151754 [details]
kmcshell_font_dialog

Attachment is discussed in comments #110 and #111. It shows that the options for subpixel hinting are only partially enabled in KDE 3.5.7.

(In reply to comment #111 from Mike Fabian)

Mike Fabian > 
> Your build didn't enable the subpixel hinting because the rpm macro used in
> freetype2.spec
> looks like this:
> 
>     %define enable_subpixel_rendering 0%{?opensuse_bs}
> 
> (off in a regular SuSE build, on in the openSUSE build service).
>

OK ! Thank you for the answer. This explains the compilation result from the source. 
---------------

Mike Fabian > ......
> Why do you think it was only partially enabled? Subpixel hinting was always
> enabled
> in freetype2-2.2.1 and there was no easy way to turn it off when compiling
> freetype2.
> In freetype2-2.2.2.20061027 as delivered with openSUSE 10.2, subpixel  
> hinting was already completely disabled during compile.

The original Opensuse 10.2 package I bought contains a freetype2 package 
freetype2-2.2.1.20061027-11 and not freetype2-2.2.2.20061027. My package was updated by the SUSE Updater to  freetype2-2.2.2.20061027-15. 

Regarding the "partially activated" subpixel dialog:  I attached a screenshot of the "kcmshell font" dialoque explaining what I mean by "partially" activated. You see that one can only change the option for the "hinting style", but one cannot change any of the subpixel-options (RGB, BGR, Vertical RGB, vertical BGR). My KDE has version 3.5.7-46.1 (from software.opensuse.org/download/KDE:).  
The freetype package used for that shot is "freetype2-2.2.1.20061027-15" (SUSE Update for Opensuse 10.2). 

--------------

Mike Fabian > I still don't understand what you mean by “partially disabled”.
> 
> Do you mean that you cannot switch on subpixel hinting in the KDE control
> centre, even if
> you have a freetype2 package installed which has subpixel hinting enabled?
>

See above and the attached screenshot for an explanation of "partially enabled" in the kmcshell dialoque. (No change for subpixel method RGB, BGR, ... possible).  Note in addition that changing the values of the "hinting style" in the "kmcshell font" produces changes in the font-smoothing. The font-smoothing, however, is only down with grey color pixels. 

---------

Mike Fabian >  It seems that in recent openSUSE KDE packages, the dialog to
> switch on subpixel  hinting in the  KDE control centre is gone. 
> Probably because of the possible patent problems.> 

At least it looks as if some options got disabled. See screenshot. Is this a KDE 3.5.7 artefact? Does the fact that the "hinting style" can still be changed indicate that subpixel hinting was not totally deactivated at compile time?  

--------------------

> Nevertheless you can switch on subpixel hinting manually by adding
> 
>      <match target="font" >
>       <edit mode="assign" name="rgba" >
>        <const>rgb</const>
>       </edit>
>      </match>
> 
> to your ~/.fonts.conf file.
> 

My  ".fonts.conf" contains the following lines: 

 <match target="font" >
  <edit mode="assign" name="rgba" >
   <const>vbgr</const>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintslight</const>
  </edit>
 </match>

However, this results in the attached screenshot - and grayscale rendering. 

-----------

As far as I see you did not comment on my statement regarding the difference between the OO font rendering compared to the KDE rendering? Can you confirm that there is a difference even after the installation of the new fontconfig and fonts-config rpms?  
 

Ralph Moenchmeyer> The original Opensuse 10.2 package I bought
Ralph Moenchmeyer> contains a freetype2 package
Ralph Moenchmeyer> freetype2-2.2.1.20061027-11 and not
Ralph Moenchmeyer> freetype2-2.2.2.20061027.

Yes, sorry, 2.2.2 was just a typo.

Ralph Moenchmeyer> My package was updated by the SUSE Updater to
Ralph Moenchmeyer> freetype2-2.2.2.20061027-15.

You mean 2.2.1.20061027-15.

That one has subpixel hinting disabled.

Ralph Moenchmeyer> As far as I see you did not comment on my statement
Ralph Moenchmeyer> regarding the difference between the OO font
Ralph Moenchmeyer> rendering compared to the KDE rendering? Can you
Ralph Moenchmeyer> confirm that there is a difference even after the
Ralph Moenchmeyer> installation of the new fontconfig and fonts-config
Ralph Moenchmeyer> rpms?

That is purely a problem in OpenOffice because OpenOffice still
doesn't use the system hinting settings but forces it's own hinting
settings.

Ralph Moenchmeyer>  <match target="font" >
Ralph Moenchmeyer>   <edit mode="assign" name="rgba" >
Ralph Moenchmeyer>    <const>vbgr</const>
Ralph Moenchmeyer>   </edit>
Ralph Moenchmeyer>  </match>

"vbgr" is probably wrong for you anyway, unless you have your
display rotated by 90 degrees (some TFT displays can be rotated).

All TFT displays I have seen so far, have rgb pixel order. 

Ralph Moenchmeyer> My  ".fonts.conf" contains the following lines: 
Ralph Moenchmeyer> 
Ralph Moenchmeyer>  <match target="font" >
Ralph Moenchmeyer>   <edit mode="assign" name="rgba" >
Ralph Moenchmeyer>    <const>vbgr</const>
Ralph Moenchmeyer>   </edit>
Ralph Moenchmeyer>  </match>
Ralph Moenchmeyer> 
Ralph Moenchmeyer>  [...]
Ralph Moenchmeyer> 
Ralph Moenchmeyer> However, this results in the attached screenshot -
Ralph Moenchmeyer> and grayscale rendering.

If this results in grayscale rendering, you have a freetype2 rpm
installed which has subpixelhinting *not* compiled in.

(In reply to comment #116 from Mike Fabian)
> Ralph Moenchmeyer>  <match target="font" >
> Ralph Moenchmeyer>   <edit mode="assign" name="rgba" >
> Ralph Moenchmeyer>    <const>vbgr</const>
> Ralph Moenchmeyer>   </edit>
> Ralph Moenchmeyer>  </match>
> 
> "vbgr" is probably wrong for you anyway, unless you have your
> display rotated by 90 degrees (some TFT displays can be rotated).
> 
> All TFT displays I have seen so far, have rgb pixel order. 
> 

One would think so. But very often a choice of  "RGB" for the subpiixel hinting method does not lead to satisfactory results. Especially on systems with TFTs and Nvidia cards. 

 I recently tested this on 3 different systems with several TFTs - a Samsung 244T (1920x1200) and a IIYAMA E511S (1600x1200) and a Samsung Syncmaster 193T (1280x1024). All systems have different Nvidia cards. Screen parameters were in each case read from the corresponding vendor CDs with YAST2 under SuSE 10.0, 10.1 and 10.2. Correct screen parameters,  mode and DPI values were checked with the Nvidia tools. On the SuSE 10.0 and 10.1 I used the freetype packages delivered on the SuSE DVDs. On the 10.2 system I did tests with the  M17N freetype2-2.3.5 package. Choosing standard RGB never lead to the best results.  

I got  the best rendering results in all cases with one of the vertical options - and not with the standard RGB option. Strange - but true.

By the way: The absolut best rendering results for KDE were for all TFTs achieved with  SUSE 10.2 and the freetype2-2.2.1.20061027-15 package from SUSE - i.e. with subpixel-hinting disabled and gray rendering.    


       

*** Bug 373169 has been marked as a duplicate of this bug. ***