Fonts under X were painful to use even by the standards of 1987 when X was introduced, and are just pathetic today.
With a Mac/Windows/BeOS graphics library, you as an application programmer just write code something like "Give me a Helvetica 10 point font in italic style". With X, you have to know the character set encoding, the foundry, the display resolution, the weight,... all of which leads to those wonderful font names like
Ack! Even worse, this notation *has* to be used in X resource files and other preferences.
Now, there are people like page layout specialists who actually care whether the font comes from Adobe or Bitstream. But what they want is to be able to say "Switch from the Adobe font folder to Bitstream and redisplay", not the anal level of detail that X requires.
Worse still, X is still stuck with these awful bitmap formats, several years after Mac and Windows switched to outline. (BeOS was outline from the start.) I'm not sure exactly why, but the complexity of an X font specification compared to anyone else (the "m" in field 11 *might* be important to the user) no doubt contributes.
X should be run *on top of* a window manager program, protocol, whatever you want to call it. Instead we have window managers forced to run under X.
As a 2D raster graphics library X is pretty good, certainly not perfect but workable. But not everybody wants to run 2D raster: there is 3D like OpenGL, 2D floating point like Display PostScript, even direct frame buffer access for live video.
The job of a window manager *should* be to divide up the frame buffer and stop programs from clobbering each other, nothing more. X programs would draw using X calls, OpenGL using GL, etc. But because the window manager is an X program, every other kind of graphic program is forced into using the X model of how the display works. Hence all the GLX extensions, XIE extensions, Display PostScript extensions...all of which are hacks to X to make it work right for these other kinds of graphics.
Fonts under X were painful to use even by the standards of 1987 when X was introduced, and are just pathetic today.
... all of which leads to those wonderful font names like
0 -iso8859-1"
With a Mac/Windows/BeOS graphics library, you as an application programmer just write code something like "Give me a Helvetica 10 point font in italic style". With X, you have to know the character set encoding, the foundry, the display resolution, the weight,
"-adobe-courier-bold-o-normal--12-120-75-75-m-7
Ack! Even worse, this notation *has* to be used in X resource files and other preferences.
Now, there are people like page layout specialists who actually care whether the font comes from Adobe or Bitstream. But what they want is to be able to say "Switch from the Adobe font folder to Bitstream and redisplay", not the anal level of detail that X requires.
Worse still, X is still stuck with these awful bitmap formats, several years after Mac and Windows switched to outline. (BeOS was outline from the start.) I'm not sure exactly why, but the complexity of an X font specification compared to anyone else (the "m" in field 11 *might* be important to the user) no doubt contributes.
X should be run *on top of* a window manager program, protocol, whatever you want to call it.
Instead we have window managers forced to run under X.
As a 2D raster graphics library X is pretty good, certainly not perfect but workable. But not everybody wants to run 2D raster: there is 3D like OpenGL, 2D floating point like Display PostScript, even direct frame buffer access for live video.
The job of a window manager *should* be to divide up the frame buffer and stop programs from clobbering each other, nothing more. X programs would draw using X calls, OpenGL using GL, etc. But because the window manager is an X program, every other kind of graphic program is forced into using the X model of how the display works. Hence all the GLX extensions, XIE extensions, Display PostScript extensions...all of which are hacks to X to make it work right for these other kinds of graphics.
Hugh