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. "

36 of 243 comments (clear)

  1. Still inferior by Drunken+Coward · · Score: 3, Informative

    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?
    1. Re:Still inferior by Fnkmaster · · Score: 5, Informative
      This isn't quite so true anymore. The font rendering on a modern distro (I'm using Mandrake 9.1 right now) looks comparable to or better than the font rendering on my Windows box. At least, when it's using _good_ True Type fonts, anti-aliasing, hinting, and so forth enabled in FreeType. I've seen some intermittent kerning problems in slightly older versions of FreeType (like in Mandrake 9), but these appear to be largely resolved now. For example, reading CNN or Slashdot in Konqueror, or Phoenix, on my Linux box, it's comparable in readability to on my Windows box.


      That being said, there is still a mess behind the scenes with font rendering. These non-TrueType legacy fonts sitting around should just go away. The frustration that sometimes, mystically, some fonts get anti-aliased and some don't - this isn't something end-users should have to deal with (and to the credit of the Mandrake people, I haven't yet seen any of these problems with the default fontconfig in 9.1). The real problem is the mixing together of all the "legacy" X11 fonts for old school X Windows apps with new TrueType fonts used in modern XRender/Xft apps. This creates a font management nightmare. What's worse is none of the font management programs make all this stuff crystal clear and usable, even for an experienced user.


      So yes, font management is still a big thorn in the side of the X Window System, though it's much better now than it used to be, with Xft/XRender. I don't really see why we would do anything other than A) incrementally improve those and B) make the old rendering system OPTIONAL and try to get everything in modern Linux distros ported over to used the new X rendering infrastructure.


      Rather than writing new font management subsystems for X, perhaps we should look for the longer term to alternatives to X, architectures that are cleaner for a desktop environment, where we can provide source-level compatibility for Qt and Gtk apps, and make the old X protocol a strap-on (like running an X server on a Windows box, or on Mac OS X), so that people who need to run legacy X apps can still do so, but that those who want a cohesive, aesthetically pleasing, easy-to-use desktop environment can get it.

    2. Re:Still inferior by cxvx · · Score: 5, Informative
      Simply put I hate Sun and all their software products because they have REPEATABLY shown themselves to be the microsoft of unix-land.

      You mean that microsoft has given things like NFS, Pam, Openoffice.org, Netbeans, ... to the community?
      If only that were true, then we could use more "microsofts of the unix world" :)

      --
      If only I could come up with a good sig ...
    3. Re:Still inferior by be-fan · · Score: 4, Informative

      This is total bullshit. The guy knows nothing about Xft, Stsf, or FreeType.

      1) FreeType is *very* good. With TrueType hinting enabled, the output on a standard resolution LCD is *dead identical* with the output for the Windows rasterizer. On a high-res LCD, any version of FreeType with the improved autohinters is also extremely good. I personally prefer it to ClearType's rendering, for two reasons: it doesn't require sub-pixel AA (which still causes visible color fringing in Cleartype) to look sharp, and letter shapes look more natural (less hinted, but still sharp). If you don't believe me, look at screenshots of my desktop: this and this.

      2) Rendering quality has nothing to do with Xft vs Stsf. Neither of these font services do the actual rendering; that is still handled by FreeType. These services are for font finding and font matching.

      --
      A deep unwavering belief is a sure sign you're missing something...
    4. Re:Still inferior by Fnkmaster · · Score: 3, Informative
      I really recommend doing a full upgrade to 9.1 then. It uses the latest FreeType, comes with a pre-rolled Xft-enabled Mozilla 1.3, XFree86 4.3, and you can get all the addons (hacked FreeType with "patent-be-damned" features enabled, MSFonts RPM, etc.) from Texstar's RPM archive (which you can add easily to your urpmi media list for dumb-easy updating).


      All the "clipped font rendering" issues (like your clipped S and so forth) that I had with my older Mandrake 9 installation are finally gone with my current 9.1 install, and I finally feel comfortable enough looking at the fonts that I can imagine using this desktop a significant part of my day. And some of the KDE 3.1.1 styles (like liquid) have some truly slick eye candy to them. The big problem remaining here is X's window redraw speed when you move windows around and the like. Some have claimed that the 2.5.x Linux kernels fix this with some changes to timing or interrupt parameters to make a more "desktop-friendly" kernel (like that magic constant you used to be able to tweak in the kernel to get a much more responsive desktop). Of course, the distros should have been doing this all along to make a real out-of-the-box desktop GUI experience that works and feels qualitatively fast on all modern hardware. Until they get that working, Linux just ain't going to be ready for the desktop.

    5. Re:Still inferior by mindriot · · Score: 2, Insightful

      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...

    6. Re:Still inferior by spitzak · · Score: 3, Insightful
      I have written toolkits that are portable to Windows and I must point out that your claims that "policy" is why Windows look nicer are wrong. I can make a program that completely ignores every GUI guideline and "consistency" requirement in the world, and it will still look nicer on Windows, because I can do a call that take a single string name of a font to GDI32, and then I can draw any string, and I am absolutely 100% guaranteed that the user will see nicely-rendered letters. Nice fonts have absolutely ZERO to do with that "consistent user interface" and "policy" and everything to do with the developers scrapping some back compatability and writing actualy hard code to do the job.

      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.

    7. Re:Still inferior by Anonymous Coward · · Score: 3, Interesting


      FreeType is *very* good. With TrueType hinting enabled, the output on a standard resolution LCD is *dead identical* with the output for the Windows rasterizer.

      Except no Linux distro can legally ship a product with TrueType hinting enabled. Apple has patents on TrueType hinting. So Linux fonts look worse than Windows fonts because of Apple. Ironic?

    8. Re:Still inferior by Fnkmaster · · Score: 4, Informative
      Well, I respectfully disagree. I think you and I basically see eye to eye on the idea of being able to make higher-level GUI API calls, and _presumably_, also having a higher-level protocol for communications between the "client" and "server" (or application and windowing system to get away from X terminology). We are in 100% agreement that a programmer should ALWAYS make an API call that says "render string 'foo' at location bar", rather than say "retrieve font bitmap foo, now do some internal font rendering in client, transmit back bitmap baz to server..." or whatever the hell goes in with the old school X infrastructure.


      XRender seemed to greatly improve font output quality in X. And I understand it, XRender and the Xft extensions basically do exactly what we both agree should have been done. In other words, it's already there. For example, Xft has the API call:



      void XftDrawStringUtf8 (XftDraw *d, XftColor *color, XftFont *font, int x, int y, XftChar8 *string, int len);


      Clearly this DOES let you draw a UTF-8 string on a button pretty damned easily. Now where we disagree is whether this is "good enough". I judge this based on opening up my KDE desktop and looking at the apps that I want to use. Evolution (which is better than Kmail), Phoenix, OpenOffice - shit, these are all Gtk applications. Oh wait, you mean Gtk apps don't look right with my KDE desktop? Separate themes, different theming functions (which I can't for the life of me figure out how to access without having Gnome on my machine). This is a nightmare.


      Face it. Windows at least strongly suggests policy for everything. You can always go and roll your own in Windows too. But all the normal desktop apps have consistent colors, toolbar structure, use the same fonts, render them through the same system, and so on. If everybody used Gtk or if everybody used Qt, I suppose there wouldn't be a problem, but they don't. I don't like people "innovating" with new GUI toolkits. If you need to create a custom widget for a specific app, fine, but I want one set of menus, one set of text drawing functions, etc.


      Perhaps it could be solved by a common theming system and some basic shared libraries that are developed cooperatively between Qt and Gtk so that they can still "innovate" separately all they want, but keep some of these basic functions consistent to guarantee a common look and feel without having to play ridiculous games looking for themes like BlueCurve specifically designed to look alike on both systems.

    9. Re:Still inferior by walt-sjc · · Score: 4, Informative

      Yeah, and he sure as hell did not read any of the docs at stsf sourceforge. There is a good side-by-side comparison of xft2 and stsf.

      It's quite interesting, and stsf looks like it may have certain advantages over xft2. xft2 for example does not do layout - that's an application thing (gnome uses pango according to the doc) and stsf DOES do layout. According to sun, stsf has a 30-200% performance improvement over xft2.

      stsf does NOT solve all the problems with X fonts however. They are still a god awful mess in regards to configuration.

    10. Re:Still inferior by be-fan · · Score: 2, Interesting

      .NET, the new one on KDE look. I'm using it with the sharp corners option (thanks Clee :)

      --
      A deep unwavering belief is a sure sign you're missing something...
    11. Re:Still inferior by iabervon · · Score: 2, Informative

      If only there were a function like Xutf8DrawString that would draw a UTF-8 string available if X_HAVE_UTF8_STRING were defined, along with a function like Xutf8TextExtents, and so forth...

      Er, right. If only there were a function like XftDrawStringUtf8...

      Er, right. Actually, programmers have been working on what you want. The programmers who matter for these purposes haven't been implementing buttons. Of course, the documentation, standardization, and popularization of this work has somewhat lagged, but UTF-8 string rendering has been supported by XFree86 since 4.0.2

    12. Re:Still inferior by 13Echo · · Score: 2, Informative

      Your problem is a result of the embedded Freetype libs in OpenOffice. You can force it to link to your system's libs, but it isn't perfect. Unfortunately, nobody can legally include the Freetype autohinter in their software because Apple owns a patent on the method for rendering the fonts.

    13. Re:Still inferior by nathanh · · Score: 2, Interesting
      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).

      It's a mistake to think that there's a centralised standard font system on the other platforms. Windows and MacOS both offer at least two competely unrelated font systems: bitmap fonts and TrueType fonts. It gets worse once you delve into applications. Macintosh print shops use Type 1 fonts (Postscript) and you need to load the Adobe PS extension to use those fonts onscreen. CorelDRAW used to ship with their own vector fonts (Type 1 again?) and at the time they only worked inside CorelDRAW. AutoCAD still ships with its own font renderer on Windows (.FNT format?). And several applications I'm exposed to on Windows will only use .FON fonts; the font dialogs don't even offer the TrueType fonts.

      The reality is that the other platforms are just as complicated as Linux/XFree86 w.r.t fonts. You've just been lucky because the application vendors have a lot of money and they've put a lot of effort into making everything "just work".

      The other platforms and appications have also had a good 10 year headstart on Linux. You're complaining about the state of Linux Right Now. But I remember MS-DOS. I remember Windows 3.0. I remember that it wasn't all peaches and cream back then. I remember 4 competing widget sets with Windows 95 (Borland OWL, Win16, Win32, MFC) and none of them cooperated properly. Even cut and paste was a disaster back then.

      So I guess my point is that Linux is better now than Windows was back then. Ok, sure, that's 8 years ago and it's not fair to compare Windows 8 years ago with Linux now. My point is not to denigrate Windows from 8 years ago; my point is that Linux is moving forwards. You don't go from zero to finished overnight. Linux started from way behind and is catching up nicely. Fonts right now are better than they were yesterday. Tomorrow they will be better again. In a short while I'm sure fonts on Linux will be on par with or better than the rest; because everything in Linux seems to work like that. Linux doesn't need to please you or me or "Joe Average". Linux gets better despite us. It doesn't need marketshare. It doesn't need to win a popularity contest. It will get better because people like to improve it. And Linux will win the "OS battle" precisely for that reason.

  2. Mightn't this be a good thing? by Alderete · · Score: 4, Interesting

    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?

    1. Re:Mightn't this be a good thing? by JanneM · · Score: 3, Insightful

      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.
    2. Re:Mightn't this be a good thing? by be-fan · · Score: 4, Insightful

      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...
  3. XFT2 needs the XRender XFree86 extension ... by burgburgburg · · Score: 2, Interesting
    in order to run fast enough, but Sun and other non-XFree86 X11 implementations don't support this extension?

    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?

    1. Re:XFT2 needs the XRender XFree86 extension ... by Anonymous Coward · · Score: 2, Informative
      Well, Solaris 2.9 does come with the XRENDER extension.

      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.)

  4. Hello, logic? by Anonymous Coward · · Score: 5, Insightful

    - 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.

  5. Re:restarting X by Jeffrey+Baker · · Score: 4, Informative

    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.

  6. Name change? by Quixote · · Score: 3, Funny
    to create a font library for XFree86, named Stsf,

    Maybe they should rename it to stfu...

    Baa--dum! Thank you.. I'll be here all weekend.

  7. Since it currently sucks... by Art+Popp · · Score: 5, Interesting

    ...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.

    1. Re:Since it currently sucks... by dominator · · Score: 3, Informative

      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

  8. Question... by Trashman · · Score: 4, Interesting

    How open is Opentype?

    --
    Do not read this .sig
  9. Stsf: because Xft2 doesn't use enough buzzwords by iabervon · · Score: 3, Insightful

    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.

  10. Sun fonts vs. OSS fonts by lindsayt · · Score: 2, Informative

    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
  11. Ok, fixed the fonts by duck_prime · · Score: 4, Funny
    The font rendering on a modern distro (I'm using Mandrake 9.1 right now) looks comparable to or better than the font rendering on my Windows box. [...] For example, reading CNN or Slashdot in Konqueror, or Phoenix, on my Linux box, it's comparable in readability to on my Windows box.
    So we've got the fonts looking nice on Slashdot. Will somebody now please fix the content?

    Sheesh.
  12. How this troll got Informative is beyond me by 21mhz · · Score: 2, Informative

    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.
  13. One already exists of course..... by IamTheRealMike · · Score: 4, Insightful
    One issue I think a lot of posters here are missing is that fontconfig and the rest are already deployed and working, whereas STSF isn't even completely implemented yet.

    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.

  14. Who cares about fonts? - X needs the fix. by AtomicX · · Score: 2, Insightful

    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:

    - Full integrated OpenGL rendering support
    - ClearType
    - It needs to be much faster ... need I say more.

    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.

  15. Why and old distro is a happy day. by SomeOtherGuy · · Score: 2, Insightful

    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.
  16. Eh? by number · · Score: 2, Interesting

    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.

  17. Comparison seems valid to me by zmower · · Score: 2, Interesting
    The OS news article links to a PDF file. Quick summary: They have a replacement for the Freetype lib so no apps have to be rewritten. 30% speed increase. It reads like a fair comparison to me.

    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!
  18. STSF is technically superior to Xft/Xft2/XRender by jeske · · Score: 2, Informative
    Even though they both can use FreeType as a rendering engine, these two APIs do not have the same rendering capabilities.

    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.

    1. STSF supports non-rectilinear text, including text along shaped paths. Xft/Xft2/Pango, even with XRender, does not.

      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.

    2. STSF has higher performance rendering than Xft/Xft2.

      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.

    3. STSF can be made to render fonts for older applications using core X protocols. Xft/Xft2 is a client-side technology and cannot improve old applications.

      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.

  19. Answer and it is not re-inventing the wheel by pamri · · Score: 2, Informative
    The specs are open, but the implementation is patented. ie., you can create a opentype font and release it under any license even GPL and adobe won't do anything, but the patent is on the method. Again, IANAL, but one of my friends, who is a lawyer is researching this stuff, since we use OTF'S a lot and i will try to put his research online.

    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.