[rescue] Auction link - just for grins
Jonathan C. Patschke
jp at celestrion.net
Sat Mar 5 14:10:17 CST 2005
On Sat, 5 Mar 2005, Jochen Kunz wrote:
> Often this new stuff is a step backward. E.g. kterm insted of xterm.
> Polluts the screen with menues insted a "context menue" like xterm, uses
> antialiased (TTF?) fonts that look blurry and have the wrong encoding.
> Even worse: Most of this new stuff is unable to use the good old X11
> fonts at all.
Fonts, in particular, are a sore spot with me because the new round of
X11 toys requires one to install the whole kitchen sink in order to draw
letters and is standing between me and the software I want to run on my
Solaris box. X -has- a font abstraction mechanism--the font server. Let
the FONT SERVER handle TrueType fonts and all that other garbage.
As far as the anti-aliased fonts goes, that's a hard problem to solve,
if it's one that people feel a need to solve. Windows solved it rather
elegantly; the routines for drawing strings were extended to just DTRT
if the system's color depth was sufficiently high and the user indicated
that he wanted antialiased fonts. In the case that the user didn't want
them, the old font logic was used.
This would be a sane fix--put the antialiased crap in Xlib--the CLIENT
library. Have it query the X server to find out if it supports the
EYECANDY-FONTS extension and, if so, just trust the server to DTRT,
otherwise do the composition on the client in-memory, generate a mask,
and overlay all that crap on the target drawable. If the user doesn't
specifically want AA fonts, just let the server do whatever.
The problem comes in that the "solutions" to all these non-problems are
written by kids who want it _now_ so that they can show it off to all
their friends on IRC, and it's a lot easier to hack up a convoluted
rendering library than actually extend the client and server in a
Jonathan Patschke ) "Trying is the first step towards failure."
Elgin, TX ( --Ben
USA ) (in #posix)
More information about the rescue