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?
One of the things that's always struck me about X is that the type rendering is poor, compared to the state-of-the-art rendering on contemporary commercial OSes. This has been true, in my personal comparisons, over many years. (I.e., as X advances, so does the state-of-the-art, making relative progress nil.)
I remember when I worked at Be, we licensed a renderer from Bitstream, specifically because writing a really good type renderer is exceptionally hard.
Perhaps this is an area where Open Source nees a leg up from a well-funded commercial outfit, like Sun. Can anyone comment on the actual quality of this new library, relative to existing solutions?
Why don't/won't they support the XRender extension?
Are the features available from STSF (which is under the BSD license) sufficiently better than what is available to warrant the work necessary for making the changeover?
- 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.
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.
Maybe they should rename it to stfu...
Baa--dum! Thank you.. I'll be here all weekend.
...I would welcome some kind of change.
As someone new to the internals of X (but not Unix) it took me the better part of a day to sifting through out-dated documentation and installing font software and scripts for previous versions of X and hacking out the bugs, just to get the CorelDraw fonts I paid for to be available in the GIMP. In hindsight I can see how I could have done it in about 20 minutes, but it was anything but friendly.
Havoc makes a good point:
You also still have to show the server-side stuff working with good performance and real-life significant memory savings.
But one can't put something to that test unless one develops it.
It basically comes down to: If a corporation is going to invest money in an open source development they are going to have some influence on how it's spent (in this case in terms of man hours). This influence may not be considered optimal to the other people in the movement, but it is Sun's money to spend.
And since I'm running RH 8.0, and OpenOffice, GIMP and AbiWord all have completely different font selections, I can't really see how it's going to get more fragmented.
Thank you for your efforts Sun Microsystems, I'm anxious to see the reuslts.
How open is Opentype?
Do not read this
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.
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
Sheesh.
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.
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.
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.
What's wrong with the kerning? Just look at "the" in the 20 pt Adobe Gill Sans line, comparing "th" to "he". There are problems like that throughout the 1st screenshot.
The 2nd shot featuring Konqueror is similarly disappointing. Just in the first paragraph - "Konquerer" and "filesystem" are all over the place.
Sure the antialiasing is pretty, but it's just tinsel on a withering christmas tree from the looks of things.
- HOORAY!
Are you really surprised that Havoc (Pango) and the Xft guy are pissed when their software is going to be replaced?
I seem to remember someone saying putting font rendering in on the client side was a hack caused by them not wanting to extend the X protocol. Sounds to me like Sun are doing it properly.
Oh, and the font rendering isn't tied into X so potentially all those separate ghostscript fonts could disappear.
Sig pending!
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.
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.