emul-linux-x86-xlibs-10.0 -> horrid fonts in 32-bit apps

Message

slithy · Post by **slithy** » Wed Feb 28, 2007 5:00 pm

So I upgraded to the new emul-linux-x86-xlibs (version 10, to be specific). With this version came a new freetype which has yielded ugly fonts in my 32-bit apps like firefox-bin and openoffice-bin. When I upgraded to the new freetype on my regular install, I had to adjust my anti-aliasing settings in kcontrol so the fonts wouldn't look like ass, but I don't have any options to adjust the settings for 32-bit apps. Is anyone using the new xlibs without fonts that look like sin incarnate?

overkll · Post by **overkll** » Wed Feb 28, 2007 7:28 pm

Same issue here with firefox-bin and emul-linux-x86-xlibs-10.

Did you file a bug?

sprittwicht · Post by **sprittwicht** » Wed Feb 28, 2007 9:06 pm

Same here. Mplayer-bin installed some masked emul-linux-x86 packages, after that, Opera almost killed my eyes with some _bad_ font rendering.
Reinstalled the stable emul-linux-x86-xlibs-7.0-r8 and all was fine again.
I'm a bit confused about your freetype thing. Exactly what versions did you have before and after the update? As far as I can see from the install and deinstall log, both versions of emul-linux-x86-xlibs (7.0-r8 and 10.0) contain libfreetype.so.6.3.8, so does my AMD64-freetype. By the way, don't the ebuild versions reflect the library versions, or why do I have freetype-2.1.10-r2 installed?

So you upgraded to freetype-2.2.1-r1, I guess. Did you manage to get the fonts rendered as clear as before in 64-bit apps, or does the new freetype still look worse than the old one?

slithy · Post by **slithy** » Wed Feb 28, 2007 9:41 pm

64-bits: I originally had freetype-2.1.10-r2 installed and I upgraded to freetype-2.3.1 and the fonts became blurry and horrid. I changed my anti-aliasing settings in kcontrol (I use KDE) and the fonts returned to how they looked before the upgrade.

32-bits: This last weekend, I upgraded the emul-linux-x86-xlibs from 7.0-r8 to 10.0 (which would include a upgrade for freetype) and my fonts in all my 32-bit apps looked blurry and horrid. Not knowing how to adjust any of those 32-bit fonts since they weren't using the AA settings that fixed the fonts when I upgraded freetype for 64-bits, I just downgraded back to xlibs-7.0-r8.

Belliash · Post by **Belliash** » Thu Mar 01, 2007 1:54 pm

[morpheouss]::[PECET]/<*> epm -qa | grep emul
emul-linux-x86-baselibs-10.2
emul-linux-x86-bjdeps-0.2
emul-linux-x86-compat-1.0-r3
emul-linux-x86-java-1.6.0
emul-linux-x86-xlibs-10.0
emul-linux-x86-qtlibs-10.0-r1
emul-linux-x86-sdl-10.1
emul-linux-x86-soundlibs-10.0-r1
emul-linux-x86-qtcurve-0.46.4-r1
emul-linux-x86-gtklibs-10.0
emul-linux-x86-medialibs-10.2

and have no troubles... fonts look great!

overkll · Post by **overkll** » Thu Mar 01, 2007 4:46 pm

A simpler command to see which emul-linux-x86 packages are install:
"equery l emul-" ( that's a lower case L )

Code: Select all

# equery l emul-
[ Searching for package 'emul-' in all categories among: ]
 * installed packages
[I--] [ ~] app-emulation/emul-linux-x86-baselibs-10.2 (0)
[I--] [ -] app-emulation/emul-linux-x86-compat-1.0-r1 (0)
[I--] [ ~] app-emulation/emul-linux-x86-gtklibs-10.0 (0)
[I--] [ -] app-emulation/emul-linux-x86-java-1.4.2.03-r2 (1.4.2)
[I--] [ -] app-emulation/emul-linux-x86-java-1.5.0.10 (1.5)
[I--] [ ~] app-emulation/emul-linux-x86-medialibs-10.2 (0)
[I--] [ -] app-emulation/emul-linux-x86-qtlibs-10.0 (0)
[I--] [ ~] app-emulation/emul-linux-x86-sdl-10.1 (0)
[I--] [ ~] app-emulation/emul-linux-x86-soundlibs-10.0 (0)
[I--] [ ~] app-emulation/emul-linux-x86-xlibs-10.0 (0)

There is already a bug filed for this issue - bug 167632

To summarize, freetype is the cause. The freetype package included with emul-linux-x86-xlibs-10.0 was compiled with USE=bindist due to licensing issues. This mucks up the fonts.

The way I see it, there are options:

1. If already downgraded to 7.0-r8, just copy /usr/lib32/libfreetype.so.6.3.8 to a temp location:

Code: Select all

# cp -a /usr/lib32/libfreetype.so.6.3.8 /tmp/

Upgrade to 10.0 and move /tmp/libfreetype.so.6.3.8 back to /usr/lib32/

Code: Select all

# mv -i  /tmp/libfreetype.so.6.3.8 /usr/lib32/

2. If 10.0 is already installed, one could download 7.0-r8, extract libfreetype.so.6.3.8, and replace /usr/lib32/libfreetype.so.6.3.8.

I did step one and it solved the font issue.

EDIT: See alternative method on page 2

Belliash · Post by **Belliash** » Thu Mar 01, 2007 6:29 pm

@overkll: I haven't done this and have no troubles with fonts...

overkll · Post by **overkll** » Thu Mar 01, 2007 6:43 pm

You must be the lucky one.

My fonts aren't terribly bad, but the difference IS obviously visible when comparing amd64 firefox and firefox-bin.

FYI, emul-linux-x86-bjdeps and emul-linux-x86-qtcurve aren't in the current portage tree. Are they remnants of an old install or custom ebuilds? I can't even find dead files for them in CVS.

STrRedWolf · Post by **STrRedWolf** » Sat Mar 03, 2007 4:26 pm

Check your ~/.fonts.conf file, and see if there's any references to antialiasing. If there isn't, you may want to rename the file to a backup, and see if it gives you a better configuration. I noticed this between my desktop's LCD monitor and my laptop which didn't recycle old configurations.

spaceLem · Post by **spaceLem** » Sat Mar 03, 2007 4:48 pm

overkll wrote: To summarize, freetype is the cause. The freetype package included with emul-linux-x86-xlibs-10.0 was compiled with USE=bindist due to licensing issues. This mucks up the fonts.

The way I see it, there are options:

1. If already downgraded to 7.0-r8, just copy /usr/lib32/libfreetype.so.6.3.8 to a temp location:
Code: Select all
# cp -a /usr/lib32/libfreetype.so.6.3.8 /tmp/
Upgrade to 10.0 and move /tmp/libfreetype.so.6.3.8 back to /usr/lib32/
Code: Select all
# mv -i  /tmp/libfreetype.so.6.3.8 /usr/lib32/
2. If 10.0 is already installed, one could download 7.0-r8, extract libfreetype.so.6.3.8, and replace /usr/lib32/libfreetype.so.6.3.8.

I did step one and it solved the font issue.

I did this and it fixed the ugly fonts within firefox, thunderbird and openoffice, but then I got a new problem: the save file dialogues for firefox and thunderbird now show fonts made entirely of squares (sort of like placeholders for a font).

I can't figure out what would cause that. Anyone got any ideas?

overkll · Post by **overkll** » Sat Mar 03, 2007 7:35 pm

STrRedWolf wrote:Check your ~/.fonts.conf file, and see if there's any references to antialiasing. If there isn't, you may want to rename the file to a backup, and see if it gives you a better configuration. I noticed this between my desktop's LCD monitor and my laptop which didn't recycle old configurations.

I don't have a ~/.fonts.conf file.

spaceLem wrote:I did this and it fixed the ugly fonts within firefox, thunderbird and openoffice, but then I got a new problem: the save file dialogues for firefox and thunderbird now show fonts made entirely of squares (sort of like placeholders for a font).

I can't figure out what would cause that. Anyone got any ideas?

I ended up making my own 32bit freetype-2.1.10-r2.tbz2 package from my 32bit Athlon64 machine, then copied that to /usr/portage/distfiles/ on my 64bit Athlon64 machine. Using an ebuild overlay for emul-linux-x86-xlibs-10.0 with no changes, I then installed the xlibs pkg. I only had to change /usr/lib to /usr/lib32 in the tbz2 package.

I don't experience the save file dialog issue you describe.

Maf · Post by **Maf** » Sat Mar 03, 2007 8:56 pm

Here's my problem with emul-linux family;)
When installed, pages looks this way:
http://gorski.at/pub/bad.png
While they actually should look this way:
http://gorski.at/pub/good.png
When I remove mozilla-firefox-bin and emul-linux stuff, pages in mozilla-firefox look correct.
Is this related to your problem? How to solve this?
BTW:

Code: Select all

[ebuild   R   ] media-libs/freetype-2.1.10-r2  USE="zlib -bindist -doc"

lsm · Post by **lsm** » Sat Mar 03, 2007 9:21 pm

overkll wrote:The freetype package included with emul-linux-x86-xlibs-10.0 was compiled with USE=bindist due to licensing issues. This mucks up the fonts.

The way I see it, there are options:

What about removing the USE=bindist from the ebuild, rebuilding the digest and recompiling freetype-2.3.1 instead?

nkmcc · Post by **nkmcc** » Sat Mar 03, 2007 11:52 pm

overkll wrote: The way I see it, there are options:

1. If already downgraded to 7.0-r8, just copy /usr/lib32/libfreetype.so.6.3.8 to a temp location:
Code: Select all
# cp -a /usr/lib32/libfreetype.so.6.3.8 /tmp/
Upgrade to 10.0 and move /tmp/libfreetype.so.6.3.8 back to /usr/lib32/
Code: Select all
# mv -i  /tmp/libfreetype.so.6.3.8 /usr/lib32/
2. If 10.0 is already installed, one could download 7.0-r8, extract libfreetype.so.6.3.8, and replace /usr/lib32/libfreetype.so.6.3.8.

Method 2 worked for me - thanks.

slithy · Post by **slithy** » Sat Mar 03, 2007 11:57 pm

1. If already downgraded to 7.0-r8, just copy /usr/lib32/libfreetype.so.6.3.8 to a temp location:
Code:
# cp -a /usr/lib32/libfreetype.so.6.3.8 /tmp/

Upgrade to 10.0 and move /tmp/libfreetype.so.6.3.8 back to /usr/lib32/
Code:
# mv -i /tmp/libfreetype.so.6.3.8 /usr/lib32/

2. If 10.0 is already installed, one could download 7.0-r8, extract libfreetype.so.6.3.8, and replace /usr/lib32/libfreetype.so.6.3.8.

This is a huge hack that is bound to cause breakage. All that you are doing is upgrading the rest of the binaries in emul-linux-x86-xlibs while not upgrading the freetype. Anything that depends on the new version of freetype will cause problems. I would not recommend doing this.

nkmcc · Post by **nkmcc** » Sun Mar 04, 2007 12:13 am

slithy wrote:This is a huge hack that is bound to cause breakage.All that you are doing is upgrading the rest of the binaries in emul-linux-x86-xlibs while not upgrading the freetype.

I agree that's all it is. And yeah, there's a pretty good chance it'll break something. On the other hand I don't think I have much that depends on 32-bit xlibs.

If something breaks, I can just reinstall the new emul-linux-x86-xlibs to fix it, and try a different approach then.

overkll · Post by **overkll** » Sun Mar 04, 2007 2:57 am

slithy wrote:This is a huge hack that is bound to cause breakage. All that you are doing is upgrading the rest of the binaries in emul-linux-x86-xlibs while not upgrading the freetype. Anything that depends on the new version of freetype will cause problems. I would not recommend doing this.

1. Yes, its a hack.
2. AFAIK, the same version of freetype is in both xlibs-7.0.r8 and 10.0.
3. If freetype is upgraded in subsequent versions of xlibs, I can compile in a matching version of freetype in 32bit mode w/o the "bindist" use flag and replace libfreetype again.
5. No breakage here.
4. Do you have a better idea?

slithy · Post by **slithy** » Sun Mar 04, 2007 8:09 am

AFAIK, the same version of freetype is in both xlibs-7.0.r8 and 10.0. If freetype is upgraded in subsequent versions of xlibs, I can compile in a matching version of freetype in 32bit mode w/o the "bindist" use flag and replace libfreetype again.

I was not aware of the fact that the version of freetype was the same in both versions. Why was the bindist USE flag added in the new version?

overkll · Post by **overkll** » Sun Mar 04, 2007 4:47 pm

overkll wrote:There is already a bug filed for this issue - bug 167632

To summarize, freetype is the cause. The freetype package included with emul-linux-x86-xlibs-10.0 was compiled with USE=bindist due to licensing issues. This mucks up the fonts.

The bug link here:

IIRC and without reading the license, one cannot distribute a binary version of freetype with the best font rendering engine turned on. That act violates the licensce. So you have to compile it yourself.

Anyone, feel free to correct me if I'm wrong.

In the freetype-2.1.10-r2 ebuild:

Code: Select all

use bindist || append-flags -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER

The USE flag bindist basically turns off "define TrueType" (DTT).

From the source code of freetype:

The TrueType bytecode interpreter is disabled in all public releases
of the FreeType packages for patents reasons (see
http://www.freetype.org/patents.html for more details).

bjorntj · Post by **bjorntj** » Sun Mar 04, 2007 5:52 pm

Can anyone tell me exactly how to change the ebuild and how to compile it afterwards? I have not yet the knowledge on how to do this....

Regards,

BTJ

bjorntj · Post by **bjorntj** » Sun Mar 04, 2007 6:02 pm

bjorntj wrote:Can anyone tell me exactly how to change the ebuild and how to compile it afterwards? I have not yet the knowledge on how to do this....

Regards,

BTJ

Never mind... I just compiled freetype in my 32 bit chroot environment and reinstalled it in my 64 bit environment... Worked like a charm...

BTJ

overkll · Post by **overkll** » Mon Mar 05, 2007 1:03 am

bjorntj wrote:Never mind... I just compiled freetype in my 32 bit chroot environment and reinstalled it in my 64 bit environment... Worked like a charm...

It would be great if an overlay ebuild was created to compile freetype in 32 bit mode and replace the emul-linux-x86-xlibs freetype library. I know this is possible. emul-linux-x86-compat supplies 32 bit glibc and gcc, along with other necessary 32bit libs. In fact. app-emulation/wine compiles in 32 bit mode on amd64 machines using such a method.

Anyone have enough ebuild experience to contribute?

kristoffer · Post by **kristoffer** » Mon Mar 05, 2007 1:14 am

I too had this problem after upgrading some emul-linux-x86 libs. My fix was to deactivate anti-aliasing and then re-activate them again through kcontrol (for KDE users, but I guess it is possible without it some how). Might be worth a try.

slithy · Post by **slithy** » Mon Mar 05, 2007 6:35 pm

kristoffer wrote:I too had this problem after upgrading some emul-linux-x86 libs. My fix was to deactivate anti-aliasing and then re-activate them again through kcontrol (for KDE users, but I guess it is possible without it some how). Might be worth a try.

I am confirm that this doesn't fix the issue. The problem is that the 32-bit freetype was compiled with the bindist USE flag.

I am currently using the 10.0 xlibs with a recompiled version of freetype. I then ran into the problem of the firefox gtk file picker having squares for fonts. Not really liking the gtk file picker anyways, I just changed the file picker to one which I think is the firefox built in one. I did this by going to about:config and changing the ui.allow_platform_file_picker boolen to false.

dmpogo · Post by **dmpogo** » Mon Mar 05, 2007 8:36 pm

slithy wrote:
kristoffer wrote:I too had this problem after upgrading some emul-linux-x86 libs. My fix was to deactivate anti-aliasing and then re-activate them again through kcontrol (for KDE users, but I guess it is possible without it some how). Might be worth a try.
I am confirm that this doesn't fix the issue. The problem is that the 32-bit freetype was compiled with the bindist USE flag.

I am currently using the 10.0 xlibs with a recompiled version of freetype. I then ran into the problem of the firefox gtk file picker having squares for fonts. Not really liking the gtk file picker anyways, I just changed the file picker to one which I think is the firefox built in one. I did this by going to about:config and changing the ui.allow_platform_file_picker boolen to false.

I have also that, and square boxes in acroread and mplayer-bin. There are lots of errors about some pango libraries not found when I launch them from the terminal