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. "
- If Sun's project is vastly inferior, no one will use it and it won't cause "fragmentation".
- If Sun's project is vastly *superior*, then the people who switch to it will enjoy a great implementation. You shouldn't force Sun to collaborate in this case. Mozart's compositions wouldn't be as good if he had been forced to "collaborate" with the inferior composers of his time.
- It's only if Sun's project is "comparable" to previous projects that it will cause fragmentation.
A leg up isn't sufficient. Problem is, a lot of technologies in the font rendering area are patented. For instance, there is no _really_ good hinting engine enabled for truetype fonts, simply because it's patent ecumbered and would require licence fees for every desktop using it. That is not to say a hinting engine isn't available, just that it's not compiled in...
Trust the Computer. The Computer is your friend.
From Sun's side-by-side comparison, it seems like Xft2 is a carefully designed project taking into account the needs of application designers to reach a clearly defined goal, whereas Stsf is has vaguely-defined and excuses its unjustified design with a lot of buzzwords.
Xft2 is slightly inferior in that it doesn't have a way of communicating the data to the server pre-rasterization, so that the server can use hardware acceleration in the rendering process. Of course, there's no particular reason that, once XRENDER is complete, this couldn't be done.
From all indications, it appears that stsf uses FreeType as a backend renderer. FreeType, in recent versions (2.1.3, 2.1.4) is extremely good. Have you taken a look at it lately?
A deep unwavering belief is a sure sign you're missing something...
Sun ruins everything
First they fucked up gnome.
I actually LIKED gnome 1.4, but when kde 3.0 came out it sent it to it's grave. The bastardised gnome 2.0 was a joke thanks to sun.
Then they gave us openoffice. Their bloatware is worse than microsoft! 78 megs download compared to just 15 for koffice or 12 for abiword.
Now they want to fuck up our fonts too? Fontconfig/xft2 is good enough already. Please tell sun to shove it and go back to cde on slowlaris. (and rewrite slowlaris in java too).
Hmm... yes, the font rendering in X might be good. But what the Linux world really is missing is a centralized, standard font system for all applications. I can certainly enjoy nice on-screen fonts. But try writing a document using the app of your choice, and then printing it. OpenOffice is on the right way (at least it manages to use TrueType fonts to print correct PostScript documents). But currenty it's a real pain to be able to pick any font on the system by its unique name, and then go and use this same font for on-screen rendering and printing. While it might be possible to make this work, it's a pain to do that. Just think about the mess of directories on your system that contain fonts. On my Debian Testing box, there's /usr/X11R6/lib/X11/fonts, and there's /usr/share/fonts; and to be able to use my TrueType fonts in OpenOffice, I have them all in $HOME/.openoffice/1.0.1/user/fonts. A software using these TT fonts to print will most likely have to embed the font data. It can not refer to the font name in PostScript as it can in X. Where is that a problem? Last time I tried, when I wanted to use a vector graphics program (sketch, kontour, ...) and write some text using my installed fonts, I would be disappointed as soon as it came to printing. So either it didn't work, or it was just way too much of a hassle to make work.
That being said, here comes the disclaimer :-) I might be wrong on how printing and X fonts interoperate... but I would definitely be interested in a way to set up proper font handling (as good as it gets) that does not cause as much confusion.
Oh, and then on Debian there's defoma... what does that do? For me (<- dumb user in this respect ;-)) it seems to make it all even more complicated...
That means STSF doesn't have to be just a little bit better, it has to be VASTLY better to justify ripping out a brand new font architecture. Nobody is convinced it is.
Other people seem to be of the belief that having 2 competing font systems is ok. It's not - this is two competing interfaces, NOT implementations. Well, STSF can apparently emulate Xft, but you don't get any advantages that way, so what's the point?
So STSF had better be pretty amazing to justify it. Sure, Sun can go and use it if they like, but it'd require major b0rkage of GTK, and those patches would probably not make it back into the trunk, so they'd have basically forked GTK. Not good.
Unfortunately the fact that X sucks is being used to force very bad ideas (such as toolkits in the server) that would condemn Linux to being totally unable to compete with any platform that allows innovation in the user interface.
What X needs is easy to program for and advanced rendering capabilities. I can draw a damn button, what I can't draw right now is UTF-8 text. Programmers using "consistency" as an excuse to force people to use their own implementation of a button, rather than getting to work on hard stuff like rendering, are causing more damage to Linux (and Windows, too!) than anything.
The problem isn't the fonts or various bits and bobs here and there - the problem is that X itself is a complete and utter piece of shite. It was written a long time ago and it is time to scrap X entirely and rewrite it from the ground up with:
... need I say more.
- Full integrated OpenGL rendering support
- ClearType
- It needs to be much faster
Sure these are available via add-ons in the vast majority of cases, but it isn't neat and the system wasn't designed with that flexibility in mind. It would be much tidier if these were all integrated into the re-designed "kernel" of X.
Try crawling through the internals of any recent "desktop" distro to find all the different font solutions working "together" to render your desktop apps and X window system, and you will soon find that no two applications seem to use the same solution. Even better yet try turning them all of for a sanity check. Anti alias this, font config that, it's a mess. Maybe no one will agree with me -- but I spent a month wondering why one application looked fine, and another looked pukey, and another looked like it would never render anything above 7 pixels. 500+ fonts installed -- and no single application could use more than a handful of them. And no two applications across graphics libraries (gtk1, gtk2, gtk2 antialias, qt, qt anti alias, etc.) seemed to use the same handful. I finally decided to go back to the days where applications just used the default font server provided by launching Xwindow. I downloaded the "ancient" xfstt and imported my favorite TT Fonts -- and I was up and running with Debian stable. The only problem I have now is trying to get slightly newer verisons of some of my apps.....Some of this stuff in Debian stable are stuck in the point release my Grandfather used in his day.
(+1 Funny) only if I laugh out loud.