The Grand Unified Desktop
Have we covered all that is needed to build a Grand Unified Desktop? Certainly not. Consider Red Hat 8.0. Almost everybody, including those who hate the idea of a GNOME/KDE hybrid, agreed that at least the fonts look much better than before. The way to duplicate this particular bit of magic on your distribution of choice is well known.
First, the improvement is due to anti-aliasing, which makes characters smoother by adding pixels in the proper places. Figures 2 and 3 show the same text in a standard xterm and in an anti-aliased one.
Second, Red Hat 8.0 is the first mainstream distribution to have used as much UTF-8 encoding as possible (more on this later) and the new client-side font-management system implemented by the xft2 and fontconfig libraries.
Basically, fontconfig can figure out what fonts are available in the system and which is best for each document. Once this is known, xft2 can tell the X server what to draw. Both libraries need to interact with FreeType or an equivalent rasterizing engine. In other words, font detection and rendering have been cleanly separated but packaged in a way that any client can embed. This means that:
Eventually, font servers should not be needed anymore.
Installing new fonts, even without the root password, is much easier.
Any application using fontconfig reads all font configurations from the same XML file(s), which can be edited by any front end.
Font management (in any application) can now proceed at the speed of these two libraries, not at the speed of X itself.
Because fontconfig doesn't require xft2 or any other X-related element, it can be embedded in anything that deals with fonts, including print drivers and libraries. libgnomeprint22 is doing exactly that.
Another nice thing about the xft2/fontconfig system is that it is not an all-or-nothing deal. It can coexist peacefully with traditional font servers, which still may be needed to assist older applications. This is what happens with Red Hat 8.0. And, xft2 can talk to both old and new XFree86 servers. The first ones receive long sequences of low-level drawing instructions. The others, compiled with the Render extension, receive faster, more sophisticated commands.
When drawing nice symbols is only half of the work and an application also needs advanced text layout, the tool of choice is Pango, which uses fontconfig. Pango is another tool born inside a more or less monolithic desktop, GNOME, but currently is developed to be usable in any other environment.
One last word about fonts—nicer drawings are cool, but if they were only used for digits and the English alphabet, they wouldn't really be worth the effort, would they? Moving to Eastern European, African or Asian languages, ASCII can't even handle “Hello, World!”
For developers, this means any new application must be coded to deal with multilanguage encodings from day one, and all existing programs must be at least checked to guarantee that they still will work. This is not merely a suggestion. If you think you are safe because you only use ASCII and only write some scripts, think again. The next time you upgrade and your code is catapulted into an internationalized shell, terminal or window manager, it will break. My Perl one-liner for random e-mail signatures stopped working for this very reason on Red Hat 8.0, and in almost three months, no one on three different lists could suggest a solution.
The character encoding that is becoming the standard on Linux is Unicode UTF-8 [see “Unicode” by Reuven M. Lerner in the March 2003 issue of LJ]. The good news is that it can represent all characters existing on the planet, so no other encodings are necessary. Figure 4 shows Emacs, as packaged in Red Hat 8.0, dealing with all kinds of symbols and characters. The bad news is that because non-ASCII characters take more than 8 bits and sometimes much more space on screen, many deeply ingrained dogmas, starting with the equation “1 character = 1 byte”, simply disappear. The right resources to deal with this, apart from the Linux Unicode HOWTO, are the mini-guide to “UTF-8 soft and hard conversion” and the UTF8_STRING mechanism that aims to preserve the X cut-and-paste system in a UTF-8 world. At a higher level, programming for internationalization, regardless of the operating system, is the goal of Openi18n.org.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
|NTPsec: a Secure, Hardened NTP Implementation||Mar 30, 2017|
|SUSE Linux Enterprise High Availability Extension||Mar 29, 2017|
|Hybrid Cloud Storage Delivers Performance and Value||Mar 29, 2017|
|smbclient Security for Windows Printing and File Transfer||Mar 28, 2017|
|How to Calculate Flash Storage TCO||Mar 27, 2017|
|Non-Linux FOSS: Don't Drink the Apple Kool-Aid; Brew Your Own!||Mar 27, 2017|
- NTPsec: a Secure, Hardened NTP Implementation
- smbclient Security for Windows Printing and File Transfer
- Hybrid Cloud Storage Delivers Performance and Value
- SUSE Linux Enterprise High Availability Extension
- Returning Values from Bash Functions
- Non-Linux FOSS: Don't Drink the Apple Kool-Aid; Brew Your Own!
- William Rothwell and Nick Garner's Certified Ethical Hacker Complete Video Course (Pearson IT Certification)
- Hodge Podge
- HOSTING Monitoring Insights
- Three EU Industries That Need HPC Now