Slashdot Mirror
The Next XFree86 Wars: XFT2 vs STSF
NoSun writes "Sun's latest project is to create a font library for XFree86, named Stsf, that would replace Fontconfig and Xft2. But the big question is: Does the world need yet another X font library that would create more incompatibility and fragmentation? Well known Gnome and GTK+ developers are against this (yet another) X font library which just re-invents the wheel one more time with the result of slowing down KDE and Gnome in the desktop race. "
The font rendering system in Windows is still vastly superior to any free implementation. Fragmentation will only further this problem.
Competition is a good thing, but in this case collaboration is even better. The more situations we have like this, the longer it will take for Linux to be ready for the desktop.
Have you been stalked by Seth today?
Ignorance strikes again. It is not necessary, just add a font to the fontconfig directory (~/.fonts, for a user), and the font will be available via fontconfig/xft2. For core fonts you need xset fp rehash. In no case do you need to restart the XFree86 server.
Unfortunately it does not work.
The real underlying problem (for Sun) is that the XRENDER extension requires 32-bit frame buffers. Sun's (at least most of their) frame buffers support 8 bits and 24 bits and maybe 1 bit. Sun's bogus XRENDER probably exists in order to please {Star,Open}Office which may only need the 8-bit part.
Sun could probably upgrade the frame buffer drivers, but it is not clear that deployed cards have that extra 33% memory lying around. (For PC users that probably sounds so 1980-ish. Sorry, but that's the world on Sun.)
I don't know much about this whole thing. All I know is that I use a Sun for my desktop instead of my RedHat 7.3 box precisely because Sun's fonts are so much better than the ones in RedHat 7.3. Fonts in Solaris are substantially comparable to those in Windows, whereas those in Red Hat still lag behind.
Whether this has any bearing on the specific issue of XFT2 vs. STSF, I don't know. Perhaps the proposed STSF doesn't even resemble the font set in Solaris, and perhaps my RedHat font issues have nothing to do with XFT2. But regardless, I use Solaris on my desktop for font reasons, and I'm more likely to trust Sun's fonts than OSS ones simply because of my prior experience.
Of course sometimes prior experience can cause people to be stubborn, ignorant and misinformed. I'll hope that's not the case here...
I did not design this game/I did not name the stakes/I just happen to like apples/And I am not afraid of snakes-AniD
To everyone moderating the parent as Informative and Insightful: lay your crack aside.
Graphics and CORBA are independent parts of the GNOME platform, that aren't necessarily used together.
That, and other claims in the parent comment, are just rehashed old trolls. Move on.
My exception safety is -fno-exceptions.
Actually, Gimp and AbiWord use FontConfig/Xft2 either directly or indirectly (read: transparently) now, as can any GTK2 application. I suggest you go get gimp 1.3.12 and AbiWord 1.1.4. Ximian's OpenOffice will use Xft2/Fontconfig as well. Expect that to be released _soon_
Having worked on these projects, I know all too well how bad it was. The font situation *was* deeply fragmented. Fontconfig made it all better. Let's not make it suck again. IMO, Sun would do better to simply support the Render extension on their XServers, or to improve the X backend to Xft2. It *can* be done. I'm dreading Sun's results. I'm afraid they've just made a lot more work for all of the users and hackers out there.
Dom
Below I've listed several reasons that STSF is technically superior to Xft/Xft2. In addition, STSF is compatible with Xft, meaning that existing Xft applications to not have to be changed unless they want to use advanced STSF features which Xft does not provide.
When you consider that drawing through Xlib or XRender must use rectangular blocks, you will realize how hard it will be for client-side font rendering to ever efficiently support non-rectilinear text.
Graphics systems typically accelerate font rendering by caching unique rendered glyphs in video memory. With client-side rendering of glyphs, several applications cannot share the same rendered glyphs. The more applications you run on the machine, the more copies of the Arial 10pt letter "L" you will have.
Another benefit of server-side rendering is better networked graphics performance. I constantly hear Linux/X developers defending X's network model over Windows' direct rendering model. Xft does not work well over a network, and Xft2/XRender have limitations over a network which are not present in STSF. As display dot-pitch increases this will only get worse for Xft.
Xft/Xft2, because they are client-side technologies, require updating applications to get anti-aliased fonts. With STSF a server-side setting can enable antialiased fonts for old applications.
Xft was great work. It has put a spotlight on XFree font rendering and provided a solution which works today. Now our goal is to have a world-class font solution which rivals MacOS and Windows. STSF has many important features and we would not be smart to dismiss it due to a political skermish about "letting go of existing work".
DISCLAIMER: I have no connection with either XFree, Xft, Sun, STSF, or any font rendering gihad. The above statements are drawn from my own experience in the PC graphics hardware industry and time spent digging through information on Xft and STSF technologies. If you don't like what I have to say, my post comes with a money back guarantee.
And the advantages of Xft
As a programmer I know which I would rather use...
I disagree it is reinventing the wheel, but rather it prevents reinventing the wheel, since now OTF'S are being developed for each toolkit, like gtk uses pango, while the qt guys are developing their own. Having such a important feature at the X-server level is good.
Please refer to my previous post on why OTF'S are so important.