Especially the font used in the menu is rendered very badly. Using AA+subpixel hinting makes things better, but it looks more unsharp than with freetype-2.1.5 - esp the character "G". The "o" for example isn't round anymore, but the upperside looks a bit triangle like. Any way to fix this? Or what can I do to provide you with more infos? (Eg. how to find out which font is used for the menus? I haven't found unusual rendering in other apps still... net-www/mozilla-firefox-1.0-r3 -debug +gnome +java +ldap -mozdevelop -moznoxft -mozsvg -mozxmlterm -xinerama +xprint Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r8 (gcc34-x86-2004.2, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-rc3-bk10-ck1 i686) ================================================================= System uname: 2.6.10-rc3-bk10-ck1 i686 AMD Athlon(tm) Gentoo Base System version 1.6.7 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Nov 29 2004, 12:17:47)] distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.8.5-r2, 1.9.3, 1.5, 1.6.3, 1.7.9, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown/usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -fprefetch-loop-arrays -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs candy ccache digest distlocks prelink sandbox" GENTOO_MIRRORS=" ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/lportage" SYNC="rsync://linux.rz.ruhr-uni-bochum.de/gentoo-portage/" USE="3dnow 3dnowex S3TC X Xaw3d aac acpi acpi4linux alsa apm audiofile avi berkdb bitmap-fonts cddb cdparanoia cdr crypt cups curl dga divx4linux dts dv dvb dvd dvdr dvdread edl encode ext-png ext-zlib faac faad ffmpeg fftw flac foomaticdb freetype gdbm gif gimp gimpprint gnome gphoto2 gpm gs gstreamer gtk gtk2 gtkhtml hal ieee1394 imlib ithreads java javascript jpeg jpeg2k kde ldap libg++ libwww live lm_sensors lzo mad matroska mikmodmmx mmx2 monkey motif moznocompose mpeg mpi nas ncurses network nls nocd nptl nvidia oggvorbis openal opengl openssh oss pam pdflib perl pic png povray ppds python qt qtmt quicktime readline real rtc samba scanner sdl slang smime speex spell sqlite sse ssl tcpd tetex theora threads tiff transcode truetype usb videos wmf wxwindows x86 xfs xine xinetd xml xml2 xmms xprint xv xvid xvmc yv12 zlib linguas_de"
Same here... but not only in ff/tb... ALL fonts look ugly, even in xterm (with antialiasing enabled)!
*** Bug 75429 has been marked as a duplicate of this bug. ***
Some screen shots: this is with FT 2.1.5: http://fatcat.ftj.agh.edu.pl/~nelchael/mozilla-ft-2.1.5.png this is with FT 2.1.9: http://fatcat.ftj.agh.edu.pl/~nelchael/mozilla-ft-2.1.9.png
use a well hinted font like ttf-bitstream-vera for your desktop. i can't say much about the reports here because they lack a lot of info on what fonts they're actually using, what their config options are (use defaults) & how they built freetype. the pictures in the dupe look like luxi fonts to me, those are no good, at least not the ttf ones which will get used.
Acording to settings it is 'Sans'. It looked good with 2.1.5 and doesn't look good with 2.1.9. Regression?
sans is common indentifier .. do you have ttf-bitstream-vera installed or not ?
Strange: If I open FF in gnome, my menu fonts look alright (with AA), only in kde it is ugly..
I've emerged "ttf-bitstream-vera", freetype-2.1.9 and it's still broken. Fonts look very bad. From /etc/X11/xorg.conf: Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/100dpi/:unscaled" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/ttf-bitstream-vera/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/myttf/" FontPath "/usr/share/fonts/75dpi/" FontPath "/usr/share/fonts/100dpi/" EndSection My /etc/fonts/local.conf: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <!-- /etc/fonts/local.conf file for local customizations --> <fontconfig> <dir>/usr/share/fonts/ttf-bitstream-vera</dir> <dir>/usr/share/fonts/myttf</dir> <dir>/usr/share/fonts/TTF</dir> <!-- Enable sub-pixel rendering <match target="font"> <edit name="rgba" mode="assign"><const>rgb</const></edit> </match> --> </fontconfig> /etc/fonts/fonts.conf is not touched by me.
True, since 2.1.9, fonts look ugly in whole Gnome. Especially the Vera Fonts. Vera Sans Mono has very bad shapes now. The whole right side of "H" is missing. The only font looking right is a font i use for menus for which i turned AA off.
Same here. I use bitstream vera and in gnome-2.8.1, firefox-1.0-r3 and xterm-196-1 vera looks ugly compared to freetype-2.1.5-r1. Everything depending on freetype is probably hit by this. Am happy to provide more details if desired.
Frankly, my Vera fonts still look great w/ 2.1.9 and subpixel rendering. I don't have any problem with parts of them being cut off, as the reporter suggested. In fact, my Vera Mono is rendered _better_ and not cut off at sizes where it was with 2.1.5-r1.
This also applies to me, http://turbogfx.homelinux.org/imgfiles/screenshot.png. Looks terrible on the navigation bar. ADDITIONALLY, maybe this deserves its own bug: PCF fonts seem not to be supported anymore!?
Nevermind about the PCF fonts. That seems to be a problem with just one font, ProFont, don't know if it's a freetype pcf format reading problem or not, but whenever that font is used, the program using it crashes upon trying to display a glyph.
So, now all we need is to have freetype 2.1.7 back in portage, which was for some reason removed. That's the one needed to keep gimp 2.2 happy and fonts looking good. Please, put it back in...
I think the main problem here is local malconfiguration, not FT 2.1.9 .
*** Bug 75475 has been marked as a duplicate of this bug. ***
Well, if I get a good guide on how to configure the fonts properly, I would be happy. I can't remember touching anything of the config files...
i've added freetype-2.1.9-r1 which contains a patch that should fix the one major issue i could find existing with the bci . Give it a try. Don't forgot you are using ~arch, that means you do agree to test stuff. Suggesting something to be masked again without investigation is not constructive in any way.
Solves the problem for me
YES, here fonts are back normal, as well. :-)
Only problem I see is, that Bitstream Vera Monospace in size 8 is broken... the right sides of all letters are partly missing... size 9 or 7 work this is with the standard font config
With 2.1.9-r1 everything is ok :) Thank You.
Makes the agfa-licnesed font from NLD9-- Albany AMT -- (sharing a box for work, just separate partitions) look very nice. But the end of the ebuild still tells me the Bytecode Interpreter is disabled?
to enable the bytecode interpreter, just add "-bindist" to your USE flags, and re-emerge freetype hth merry xmas
I put together a small collection of what some other distributions are using. Feel free to try out any of the patches and report on them. Note that both Fedora and Mandrake are using 2.1.9, and I couldn't find what SuSE was doing in 9.2, only 9.1. http://dev.gentoo.org/~spyderous/xorg-x11/suse/freetype2-2.1.7-53/ http://dev.gentoo.org/~spyderous/xorg-x11/redhat/freetype-2.1.9-1/ http://dev.gentoo.org/~spyderous/xorg-x11/mandrake/freetype2-2.1.9-2mdk/
I can also confirm freetype-2.1.9-r1 fixes the problem (at least with sans -- Proggy fonts still look crappy, but I doubt it's FT's fault).
Same here. fixed with 2.1.9-r1.
Well the SuSE patches don't apply cleanly to 2.1.9 and the others are nothing significant regarding bytecode interpreter: http://www.freetype.org/freetype2/2.1.3-explained.html#bytecode also for me it says it isn't enabled although I have USE=-bindist and the TT_CONFIG_OPTION_BYTECODE_INTERPRETER is defined...
but it's just saying that the bytecode interpreter isn't enabled... I've compiled FT with USE=bindist and the fonts look really ugly and btw... the bytecode interpreter seems to be disabled in the SuSE RPMs but their fonts look much better...
the bytecode interpreter is enabled/disabled message can't work the way it's implemented now... there's no longer TT_Goto_CodeRange (exactly there is nothing with CodeRange)... maybe we shall grep for FT_MulDiv_No_Round as this is only in the bytecode enabled freetype
I didn't see a fix on 2.1.9-r1, neither did a manual uncomment on the bytecode interpreter macro. Now I'm in 2.1.5-r1. I found sth on the freetype maillist: ------------------------------------------------------ > I have a problem since moving to freetype2.1.9 with the bytecode > interpreter enabled. There seems to be some blurring with fonts when > they are approximately horizontal. Going back to freetype2.1.7 > fixes this problem. I'm not sure how much you support the bytecode > interpreter but I thought I'd give you a heads up about this > problem: Pleae try the current CVS; a serious bug in the TT interpreter has been introduced in 2.1.8 and fixed recently. Werner ----------------------------------------------------------------- There's a 2.1.10 to be released soon according to the maillist. We'd better wait for that.
well I'm going to assume it's fixed. comment #31 : didn't read the whole thread obviously, the patch in 2.1.9-r1 is the 'severe problem'. comment #28 : afaics that still works, anyway the thing is more of a debug thing & not really meant for users anyway.
