My bad, I was unclear in what I was saying. I did not mean to say that the old font system was
superior, as it clearly lacked many features needed for fast high quality text rendering. What
I do belive is that a font rendering system that rasterizes fonts on the server side but gives
access to font metrics on the client side as well should be possible to create, thus giving
you full performance and full access to graphical goodies. The best way to do this with as
little latency as possilbe might be to allow the client to calculate font meterics but leave
all actual rendering to the server.
Posted Feb 12, 2008 2:42 UTC (Tue) by jamesh (guest, #1159)
[Link]
Sun tried this with STSF:
http://stsf.sourceforge.net/about.html
It was not exactly a success, but did offer some benefits over fontconfig/Xft if you were
running hundreds of X servers from a single machine. When running just a single X server,
these benefits were not apparent and the increased complexity for developers is a clear minus.
what about....
Posted Feb 14, 2008 9:21 UTC (Thu) by liljencrantz (guest, #28458)
[Link]
I completely missed the existence of stsf, thank you for the pointer.
I read up a bit on why it failed, and the main reason (judging from mailing list posts, at
least) seems to be that the various X hackers (e.g. Havoc Pennington and various GTK hackers)
felt that fontconfig was good enough. And in all fairness, that is probably completely true if
you don't care about network transparency. I've never heard any other serious criticism
against fontconfig except for the client side rendering issue.