Linux in a Windows World/Appendixes/Linux on the Desktop
Although most of this book focuses on using Linux servers to help Windows desktop systems, Linux is beginning to find a home as a desktop OS. As a multipurpose OS, Linux can handle many desktop functions, and you may want to consider Linux in this role for many of the same reasons you'd consider Linux as a server OS—low cost, high reliability, remote administration capabilities, and so on. You might also want to use thin clients to access Linux, in which case this chapter applies to the system the thin clients access. Before deploying Linux as a desktop OS, though, you'll have to know a bit about its capabilities in this role; that's where this appendix comes in.
I begin with a look at Linux desktop applications, including a list of some common application categories and their Windows and Linux instantiations. Next is the issue of application configuration. This task is unusual in Linux because many applications, including the desktop environments that run when users log in, have both global and user configurations, so you may need to modify either type. Sometimes, you may find yourself unable to do what you want using native Linux applications, in which case Linux's ability to run Windows applications is critical, so this issue is covered. Whether or not you can use Linux applications, your ability to access data can be important. This includes both filesystem access and file compatibility across applications. Next up is a common problem area for Linux desktop systems: font handling.
Linux Desktop Applications for All Occasions
Any attempt to use Linux as a desktop OS ultimately requires Linux desktop applications that are acceptable for your intended purpose. Although tools to run Windows applications are available in Linux (as described later in the Section B.3), these solutions are imperfect. If all you do is run Windows programs, you might as well use Windows as your OS.
Fortunately, an array of desktop applications are available for Linux, as summarized in Table B-1. Of course, not all these components are exactly equivalent. For instance, some of the Linux applications, such as mutt and cdrecord, are command-line tools, whereas the Windows applications are overwhelmingly GUI in nature. Exact features also differ, of course, and, in some cases, the basic purpose of tools aren't equivalent. For instance, mkisofs and cdrecord work together to create a CD-R, while X-CD-Roast and Eroaster provide GUI frontends to these tools. In Windows, CD-R creation tools are usually all-in-one packages that do everything. To learn more about any of these programs, perform a web search or check your Linux installation medium to see if the program comes with your distribution.
Table B-1. Application categories and exemplars
|Application category||Windows examples||Linux examples|
|Office Suite||Microsoft Office, WordPerfect Office, StarOffice, OpenOffice.org||OpenOffice.org, StarOffice, KOffice, GNOME Office|
|Bitmap Graphics Editing||Adobe Photoshop, the GIMP||The GIMP|
|Scanning Software||TWAIN, VueScan||SANE, Kooka, VueScan|
|CD-R Creation||Easy Media Creator Deluxe, Nero||mkisofs, cdrecord, X-CD-Roast, Eroaster, K3b|
|Multimedia Playback||Windows Media Player, Winamp, Real||XMMS, ALSA Player, mpg123, Real, xine|
|PDF Creation and Viewing||Acrobat and Acrobat Reader||Ghostscript, Acrobat Reader, XPDF|
|Web Browsing||Internet Explorer, Mozilla, Firefox, Opera||Mozilla, Firefox, Opera, Konqueror|
|E-Mail Client||Outlook and Outlook Express, Eudora, Netscape Mail||Evolution, Netscape Mail, Thunderbird, KMail, pine, mutt|
|Instant Messenging||AIM, ICQ, MSN Messenger, Jabber, X-Chat||GAIM, KAIM, talk, Kopete, X-Chat|
|Web Site Creation||FrontPage, Dreamweaver||Quanta, Nvu|
If you don't see an application category that you need in Table B-1, don't panic! This table is intended to provide only a few quick pointers for some of the most common desktop tools. Try performing a web search on the category name and Linux. You might also check your distribution, particularly if it provides a GUI installation tool with categorized sets of software. Many Linux sites, such as http://www.linux.org, http://www.sourceforge.net, and http://www.freshmeat.net, also provide pointers to Linux software by category.
One critically important Linux desktop software component doesn't appear in Table B-1: the desktop environment. This is a collection of tools—most are fairly small by themselves—that together create the familiar set of desktop icons, program-launch tools, and so on that users see when they log in to the computer. Windows provides only one common desktop environment, which is bundled into the OS. In Linux, you have a choice between GNOME, KDE, XFce, XPde, and others. This choice is covered in more detail in Section B.2.3.
Configuring Applications and Environments
If you're familiar with administering Windows desktop systems, many of the issues involved in administering Linux desktop systems will be similar, but others are unique. Likewise, if you're already familiar with Linux system administration in other contexts (such as servers), desktop environments present some unique challenges. Some of the issues in Linux desktop configuration include understanding the difference between global and user configuration files, locating configuration files, creating default desktop configurations, and making desktop environments accessible as options at login time.
Global Versus User Configuration Files
Linux has long supported multiple users. Part of this support includes mechanisms to help keep users' configurations separate—enabling two users to use the same computer but set different defaults for assorted application and desktop environment options. Even if a computer has a single user, Linux uses these features, maintaining nominally separate global and user configuration files. You can take advantage of this distinction to set global defaults, which users can then modify without impacting other users' settings. On a system with a single user, you can use this distinction to easily restore a user's settings to the default if the user's settings become corrupt.
Typically, global configuration files are stored in a system area. These files can be used in one or both of two ways:
- User programs can access the global configuration files directly, using them to direct program operation in a way that's invariant from user to user. If a program supports only this mode of operation, users can't change their default.
- Users or user programs can copy the global configuration files to a subdirectory in the user's home directory and then access the copied files for normal operation. This approach enables users to change their personal defaults without impacting other users.
Most user programs support use of local configuration files, at least as an option. Some programs automatically copy global configuration files the first time they're run. Others use the global files directly unless users copy the global files to their home directories or create their own configuration files from scratch. Sometimes a global file serves as a template that can be modified by a local file.
Ultimately, you'll have to consult a program's documentation to learn how it treats these two types of configuration files. This knowledge can be important when setting defaults. For instance, if a program always consults a global file, you can change defaults even for users who've already begun using a program, so long as they've not explicitly changed a default; however, if a program copies global configuration files to the user's home directory the first time it's run, changing the global configuration files affects only users who begin using the program after you make changes.
The precise methods used to modify configuration files differ from one program to another. Traditionally, Unix and Linux programs have used text-mode configuration files that can be edited in a text editor. This remains true, but many of the more sophisticated GUI programs now create very complex configuration files, often using the Extensible Markup Language (XML). Such files can be difficult to modify by hand, particularly if you're not familiar with XML or the specific XML conventions used by the program in question. Thus, one approach to making changes is to create a dummy account, change the defaults using that account, and copy the dummy account's local configuration files back to the global configuration file's location.
Don't blindly overwrite existing global configuration files. If you make a mistake, doing this can render a program unusable, at least to new users of the program. Before replacing a global configuration file, back it up someplace safe. If you don't, you may need to reinstall the program should you make a mistake in creating the new configuration file.
Locating Configuration Files
One location for global configuration files is /etc/skel. This directory holds template configuration files that may be copied to a new user's home directory when an account is created, depending on the options to useradd or other account-creation tools. Once files are copied from /etc/skel, user applications don't normally access this directory. Thus, making changes to files in /etc/skel won't normally affect how existing users' applications work.
Typically, /etc/skel contains a rather small set of files—perhaps just for your system's default shells, for instance. These files are normally all dot files, meaning that their filenames begin with dots (.), which means that they don't show up in file listings unless you include special options, such as the -a option to ls.
Other directories in /etc hold many other application-specific global configuration files, often named after the programs they control. For instance, /etc/gimp holds global configuration files for GIMP, /etc/xfce4 holds global configuration files for Version 4 of XFce, and /etc/xcdroast.conf is the global configuration file for X-CD-Roast. Most configuration files in /etc, though, belong to system utilities and servers rather than user applications.
Many desktop programs store their global configuration files somewhere in their own directory tree. One good way to locate these files is to use your package management system to list all the files that belong to a package. For many packages, though, this action produces a large list of files—documentation files in multiple languages, graphics files used to display icons in the program, and so on. You might get lucky by piping the result through grep to search for a string like conf, but this procedure isn't guaranteed to work.
Programs associated with the major desktop environments (particularly GNOME and KDE) often store their global configuration files in a directory along with the desktop environment. This location can vary from one distribution to another, as described shortly.
Some programs don't ship with global configuration files per se; they store their defaults in their executables and rely exclusively on user configuration files to override these defaults. If you want to change your systemwide default for such programs, you may need to generate user configuration files in a dummy account and then copy those files to /etc/skel. This approach won't change the defaults for existing users, though.
Creating Default Desktop Configurations
Perhaps the most important type of configuration file you might want to modify is that for your desktop environment—KDE, GNOME, XFce, or what have you. Users see their desktop environments when they first log in; making frequently used programs, file shares, and so on easy to access on your network's standard desktop will go a long way to helping your users make the transition to Linux and be productive in that environment. Typically, the way you manage this task is to create a desirable template configuration in a dummy account and then to copy that template configuration to the desktop environment's global configuration file area.
Creating a template configuration
To begin the task, create a new "dummy" user—one who exists only to enable you to create a new desktop configuration. Log into this account using the desktop environment you want to modify. (If this environment isn't an option when you log in, consult the later Section B.2.4.) You can then tweak the desktop environment as you see fit. Features you might want to adjust include:
- Desktop icons
- Most desktop environments, including KDE and GNOME, enable you to create desktop icons that launch programs or open file browsers on particular directories. Creating such icons for important programs and directories can help users navigate the system. Don't go overboard, though; too many icons can clutter the desktop and be confusing, particularly for users who've never used a system before.
- Program launching menus
- Most desktop environments include a tool, often called the Panel, which houses program-launching icons. Some icons appear directly on the Panel, but more can be referenced in menus. Most distributions attempt to provide ready access to most common programs from their Panel menus, and many will automatically add programs when you install them using the distributions' package-management tools. Nonetheless, you might want to rearrange the menus, delete programs to reduce clutter, or add programs that aren't added by default. Some desktop environments, such as KDE, maintain separate global and user program launch menus. To make global changes, the best approach is to change the global file, which for KDE is called applnk and is usually located in /usr/share, /usr/kde/ version/share or a similar location.
- General desktop defaults
- Desktop environments all present numerous defaults that influence the overall look and feel of the system. These include default program fonts, desktop background images, keyboard repeat rate, window border decorations, and so on. Technically, these defaults may apply to dozens of different programs; however, most desktop environments provide a centralized control panel through which most or all of these options may be set. Although all major Linux distributions ship with defaults that are at least somewhat reasonable, you might want to change some, either because you think the default is not the best or to customize the system for your environment (say, using a background image with your company's logo).
You can set certain font defaults in a desktop environment; however, these defaults apply only to the desktop environment and to affiliated programs. You may need to change default fonts in many programs individually to make such a change truly universal. Actually installing new fonts that don't ship with the distribution is another matter, too; the Section B.5 later covers this issue in more detail.
When you're done making these changes, log out and then log back in again to be sure they're working as you intended. Some programs (particularly older ones or those that aren't officially part of a desktop environment) require you to explicitly save a configuration before its changes are saved, so it's easy to make changes and then lose them when you log out.
You may want to consult with your end users when designing a default desktop environment. Try creating two or three possible defaults and ask a few typical users to comment on them.
Copying the template to be a global configuration
Your template user's configuration is now saved in the template user's home directory. You can look for it using the -a option to ls (the -F option can also be helpful because it distinguishes directories from files).
# ls -aF /home/genie ./ .bashrc .gnome/ .metacity/ Desktop/ ../ .dmrc .gnome2/ .nautilus/ .ICEauthority .gconf/ .gnome2_private/ .recently-used .bash_profile .gconfd/ .gtkrc-1.2-gnome2 .xsession-errors
This example shows the files created by the desktop environment (GNOME in this case), as well as those copied from /etc/skel during account creation and any others created during the login process. The.ICEauthority, .bash_profile, .bashrc, .dmrc, and .xsession-errors files aren't part of the desktop environment configuration. The .recently-used file, although used by GNOME, can be safely ignored because it holds information on recently accessed files; chances are you don't need or even want to copy that information into new accounts.
To copy the template you've created so that all new users can access it, you must copy the files and directories to an area in which they'll be used by new accounts. One way to do this is to copy everything into the /etc/skel directory. When you do this, the files will be copied whenever a new account is created and its initial files set from the /etc/skel template.
Adding an Environment as a Login Option
If you want your users to be able to log into a specific GUI environment, you must be able to tell the computer to make that environment the default, or at least to present the environment you want as a default. To do this, you must first understand how to get a GUI login tool running. Once this is done, you need to know how to change defaults and present options with your tool of choice.
Running a GUI login tool
Many Linux distributions today come configured to boot directly into GUI mode by default. Most distributions, including Fedora, Mandrake, Red Hat, and SuSE, enable you to control this feature by editing a single line in /etc/inittab:
The number in the second colon-delimited field (3) in this example sets the default runlevel. Typically, runlevel 3 corresponds to a text-mode boot, whereas runlevel 5 corresponds to a full GUI boot. (Some distributions, such as older versions of SuSE, used runlevels other than 3 and 5 for these functions.) The latter is very much like the former, except that in a GUI boot, an XDMCP server is launched, as described in Chapter 11. The purpose in a default configuration isn't to provide remote access, though; the default XDMCP configuration locks down the XDMCP server so that it provides only local GUI login access.
A few distributions, such as Debian and Gentoo, do things differently: rather than use the runlevel to signal whether a GUI login should be enabled, they set a SysV startup script to do the job. You can enable or disable this startup script to change the distribution's GUI login status. Debian uses scripts called xdm, gmd, or kdm for the X Display Manager (XDM), GNOME Display Manager (GDM), or KDE Display Manager (KDM) tools, respectively. Gentoo has a single script called xdm that starts whichever tool you've chosen to use.
All distributions provide some method of selecting which XDMCP server to run. Most distributions do this by setting a variable in a configuration file. Fedora, Red Hat, and Mandrake use /etc/sysconfig/desktop; Gentoo uses /etc/rc.conf; and SuSE uses /etc/sysconfig/displaymanager. In all these distributions, you set the DISPLAYMANAGER variable. Most distributions accept either the name of the XDMCP server, such as KDM, or the name of an associated desktop environment, such as KDE. Debian works a bit differently; it sets the path to the default XDMCP program in the /etc/X11/default-display-manager file.
Presenting desktop environment options
Different XDMCP servers require different configurations to present login options to users. The simplest of these tools, and the least convenient from a user's point of view, is XDM. This server presents no login-time options; instead, it relies on a configuration file to set the default desktop environment. The global version of this file is /etc/X11/xdm/Xsession, which is often a link to /etc/X11/Xsession. Users can override this default by providing a file called .xsession in their home directories. In either case, this file is a script, so you can configure it to run a particular desktop environment by providing appropriate commands, such as gnome-session to run GNOME, startkde to start KDE, or startxfce4 to start XFce. A simple script can contain nothing but a reference to the environment startup script:
More complex scripts are possible, of course. The default XDM Xsession script typically tests for the existence of several desktop environments and, from among those that are available, starts the one that's most preferred by the distribution maintainer.
KDM and GDM are both more complex. They provide the user with a set of options, typically accessed by clicking a button in the GUI display. In most cases, when you add a new desktop environment, your KDM and GDM configurations will be modified to present the new desktop environment as an option to users. Sometimes, though, you need to take extra steps to see that this happens.
KDM and GDM both look in a directory for a list of sessions. This is often the /usr/share/xsessions directory, although it could have another name—try typing find /usr -name "*.desktop" to locate the directory if you can't seem to find it. Both KDM and GDM look for files whose names end in .desktop. These files provide information on how to launch a desktop environment. If you need to add such a file, you should probably begin by copying an existing one and modifying it. Existing files are likely to be rather long because they often contain options to set the name in multiple languages. A short example looks like this:
[Desktop Entry] Encoding=UTF-8 Name=KDE Comment=This session logs you into KDE Exec=startkde TryExec=startkde Type=Application
To modify the system, edit the Exec and TryExec lines to point to the desktop startup command. Modifying the Name and Comment lines will also enable your users to correctly identify the environment.
Many distributions install a large number of .desktop files in some other location, such as /usr/share/apps/kdm/sessions/. These files might not be used by default, but you should be able to copy them to the appropriate directory rather than create new files. If your distribution does this, you can locate it with the find command mentioned earlier.
Once you've added a new environment to the configuration, you'll have to restart the XDMCP server. In most distributions, you can do this by typing telinit 3 followed by telinit 5 at a command prompt. This action brings the system to runlevel 3, then back to runlevel 5. In the process, it shuts down the XDMCP server and restarts it. With Debian and Gentoo, you can use the SysV startup scripts to shut down and then restart the XDMCP server.
Restarting the XDMCP server also shuts down the console's X session. Thus, you should save any unsaved work before attempting this procedure.
Running Windows Programs in Linux
Linux is a mature OS that provides programs in all common, and many uncommon, desktop software categories. Nonetheless, sometimes native Linux programs just aren't adequate. Perhaps you need a specific program to read existing data files or to exchange data with colleagues, customers, or clients off-site. Perhaps you need a program with specific features that aren't available in Linux; or perhaps you need to run an exotic program for which no Linux counterpart is available. Sometimes, you can work around the limitation by running Windows programs from Linux. This approach has advantages and disadvantages compared to running the programs on a computer that runs Windows, so understanding why you might want to run Windows programs in Linux is critical. You should also know a bit about some of the options for doing the job; several tools are available, each of which has its own advantages and disadvantages.
Why Run Windows Programs in Linux?
Ordinarily, the best way to run a program is to run it on the OS for which it was designed. Any other OS will, at best, be emulating the target OS or placing an additional layer of software or protocols between you and the program you want to run. Such procedures are inevitably imperfect and often slow down operation. However, these drawbacks can be overwhelmed by certain advantages of running Windows programs in Linux:
- Reduced hardware costs
- Running Linux and Windows programs on one computer can reduce hardware costs compared to running these programs on multiple computers. Related to this advantage is the fact that a single computer consumes less power and desk space than multiple computers.
- Using non-x86 hardware
- Some methods of running Windows programs from Linux work even with non-x86 hardware. Thus, you can run Windows programs from a Linux system running on PowerPC, Alpha, or other CPUs. This may be a big plus if you already have an office filled with such computers, and you don't want to replace them or buy more.
- Easy access to Linux resources
- Perhaps you want to use resources available to Linux that aren't easily accessible from Windows. For instance, you might have large numbers of data files on a Linux desktop computer's hard disk, stored on a Linux-native filesystem. Although you can often gain access to such filesystems from Windows (either through special Windows filesystem drivers or by using another Windows system and setting up a file server such as Samba on the Linux system), doing so is sometimes inconvenient.
- Linux stability
- Linux is a very stable OS—more stable than most versions of Windows. Thus, using Linux can mean less downtime due to system crashes. This advantage is most dramatic when comparing Linux to rather old versions of Windows—particularly Windows 9x/Me. Windows 200x has a much better reputation for reliability.
- Improved productivity
- Running Windows programs alongside Linux programs can improve productivity. Many methods of doing this enable you to cut-and-paste data between programs, and it's usually easier to switch between programs on a single computer than to switch between computers. If the alternative is dual booting a single computer, running Windows programs in Linux can save a great deal of time that would otherwise be wasted rebooting the computer.
These advantages all assume that you want or need to run Linux as your primary desktop OS, either site-wide or for just a few users. They tend to evaporate if you have more compelling reasons to run Windows programs than to run Linux programs.
Options for Running Windows Programs from Linux
Broadly speaking, methods of running Windows programs in Linux fall into two categories: remote access tools and emulators. Chapter 10 and Chapter 11 describe remote access tools. For accessing Windows systems from Linux, the GUI tools are almost certainly the better choice; text-mode tools are simply too limiting for most purposes.
Of course, using remote-access tools requires you to have at least one Windows system running on your network, and that system must be running an appropriate remote-access protocol server. You can then use the corresponding Linux client to log into that Windows computer remotely. One advantage of this approach is that you can use any Linux system, provided the appropriate software is installed; you don't need to be concerned with CPU architectures or even the speed of the computer you use for access, within broad limits. Because this approach doesn't rely on any sort of emulation, software compatibility is usually quite good. After all, the software is running on a real Windows computer, meaning that the only significant source of compatibility problems is in the protocol used to communicate between systems. Games and multimedia tools sometimes have problems running over these protocols, but most productivity tools work just fine.
Another approach is to use an emulator, which is a tool that can run one operating system's programs from another. Actually, several different types of emulators exist:
- CPU emulators
- CPU emulators enable one CPU to execute instructions meant for another CPU. Using a CPU emulator, you can run x86 code on a PowerPC, SPARC, or other CPU. (Emulators for other CPUs are also available but are irrelevant for Windows emulation.) You can even run x86 code on an x86 CPU using this approach. The downside is that CPU emulators can't run software nearly as quickly as it can run on native hardware of otherwise comparable speed. The most common CPU emulator for Linux is Bochs (http://bochs.sourceforge.net), which is both a CPU emulator and a machine emulator (described next). The result is that you can run Windows within Bochs. In practice, this works best with older versions of Windows on new (hence fast) CPUs. Another CPU emulator is QEMU (http://fabrice.bellard.free.fr/qemu/), which includes a full machine emulator similar to Bochs but can also be used to launch Linux applications for one architecture on another CPU. This feature can be handy for running WINE (described shortly) on non-x86 platforms.
- Machine emulators
- Another type of emulation is machine emulation, in which the non-CPU components of a computer are emulated. That is, software running in a machine emulator "sees" a hard disk, display hardware, and so on that are emulated. The emulated disk might correspond to a file on the hard disk and an emulated display might tie in to a single window, for instance. Machine emulators typically run emulated programs directly using the host CPU, although some tools (such as Bochs) include both CPU and machine emulator components. The commercial VMware (http://www.vmware.com) is a popular machine emulator, which supports running several versions of Windows and other OSs from Linux. Win4Lin (http://www.netraverse.com) is another commercial machine emulator, but it only supports Windows 9x/Me.
- OS emulators
- An OS emulator makes minimal or no attempts to emulate the CPU and hardware; instead, it attempts to emulate the OS itself. In Linux, the most popular Windows OS emulator is the open source Wine Is Not an Emulator (WINE; http://www.winehq.org). This package duplicates the functionality of the Windows application program interface (API)—that is, the system calls used by programs. WINE can be used like a Linux GUI API to compile Windows programs as native programs, or it can be used in conjunction with a program loader to run programs compiled for Windows. Ordinarily, WINE is useful only on x86 or AMD64 systems; however, used with the QEMU CPU emulator, you can run x86 Windows programs on non-x86 CPUs. WINE runs Windows programs quickly (at least, when used on x86 hardware), but its compatibility is far from complete. Small programs and popular ones are likely to run well, but many large programs don't run or run only after extensive tweaking. Several offshoots of the WINE project exist. Most notable of these are the commercial Crossover Office (http://www.codeweavers.com) and the commercial Cedega (formerly known as WineX; http://www.transgaming.com). Crossover Office is optimized to run Microsoft Office and a few other common productivity tools, whereas Cedega is intended to run Windows games in Linux. The open source WINE can run Microsoft Office and many games; the commercial products provide easier installation and relatively minor improvements over the original.
The expansion of WINE's name deserves elaboration, given that I'm calling it an emulator. The precise meaning of the word emulator varies depending on who you ask about it. This appendix uses the word fairly broadly, to apply to any of the three types of activities just described. Some people, though, including the WINE developers, prefer to confine this term to CPU emulation, hence the expansion of the WINE name.
Generally speaking, among emulators, WINE is a very good approach, particularly on x86 systems, if you can get the program you want to run working under it. Check http://appdb.winehq.org for application compatibility information before you invest a lot of time in trying to get a program working. WINE provides the best cross-OS cut-and-paste support and enables you to run an application without actually installing Windows on your computer. (Some configurations do require you to copy some Windows .DLL files, however.) Note that WINE's list of supported applications is much shorter than that of machine emulators. These emulators run a real copy of Windows inside their virtual environments, so they can run almost any program that doesn't require access to real low-level hardware. (Some of these programs will work but compatibility is a bit hit-or-miss.) Generally speaking, you should resort to CPU emulators only if you must run Windows programs on non-x86 hardware. Although you can run Windows on an x86 Linux system in a program like Bochs, the experience is likely to be painfully slow, particularly if your computer is very old or if you try to run a recent version of Windows.
File and Filesystem Compatibility
Linux desktop systems must frequently access files created by Windows computers, or store files in a way that Windows computers can handle. This task has two components. First, Linux must be able to read and write the filesystems used by Windows, at least when files are transferred on disks. Second, Linux applications must be able to process the file formats that are most commonly used on Windows. This second task can be broken down into many categories depending on the programs in question, and in this chapter I describe office file formats, PDF files, and archive files. I also provide some tips for transitioning a network from using Windows to one that uses Linux desktop systems.
Accessing Windows Disks and Filesystems
Before you can deal with file format issues, you must be able to access the files in question. In many networked environments, the easiest way to deal with this issue is to use the network. Tools like FTP and email can be a good way to transfer files, particularly over the Internet at large. The SMB/CIFS is a common file-sharing protocol among Windows systems, and using Linux as an SMB/CIFS client is described in detail in Chapter 6.
Sometimes, though, network protocols aren't the best solution. Network bandwidth may be inadequate for delivering very large files, network firewalls might prevent data exchange, or one or both of the systems might not even be on a network. Such situations are particularly common when users want to move files between home and work. Another situation in which network access may be inadequate is when moving data across time rather than space—that is, when archiving data for long-term storage or when reading files that have been so archived in the past. In all these situations, you must be able to share data on a common disk filesystem. Several filesystems are likely to be used for such data transfers:
- The File Allocation Table filesystem is named after one of its key data structures. FAT is a very old filesystem, dating back to the earliest days of DOS—and earlier (FAT variants were used on DOS's predecessor OSs). FAT is actually a family of filesystems, which vary on two dimensions: the size of FAT entries, in bits (12-, 16-, or 32-bit) and filename length limits (short or 8.3 filenames, which can be no longer than eight characters with a three-character extension; VFAT long filenames; or a Linux-specific long filename extension). FAT size varies with disk size: floppies and very small hard disks generally use FAT-12; FAT-16 tops out at 2-GB partitions (4 GB for Windows NT/200x/XP); and FAT-32 is often used for disks larger than a few hundred megabytes, and must be used for disks larger than the FAT-16 limit. Linux auto-detects the FAT size, but you specify the nature of the filename support using one of three filesystem type codes: msdos stands for the original FAT with 8.3 filenames; vfat adds VFAT long filenames; and umsdos adds the Linux-specific long filename support to the original FAT. Note that VFAT and UMSDOS are mutually exclusive; UMSDOS and VFAT both build on the original FAT in different ways. All these drivers support both read and write access, and all are very stable and reliable. FAT (in all its variants) is most commonly found on hard disks used by Windows 9x/Me, floppy disks, Zip disks, and other removable magnetic disks.
- The New Technology File System was created for Windows NT and is the preferred filesystem for use on hard disks with all computers in the Windows NT/200x/XP family. It's seldom found on removable media, so the main reasons to access NTFS from Linux are for a dual boot configuration or if you need to recover data from an existing Windows hard disk (say, after replacing Windows with Linux). Linux provides reasonably reliable read-only support for NTFS, but read/write support is much less stable. In 2.4.x and earlier kernels, Linux's NTFS read/write support was almost certain to corrupt the NTFS partition. In the 2.6.x kernel, the NTFS read/write support is more limited in capabilities (it can modify only existing files, not create new ones), but it's less likely to damage the existing filesystem. Linux's NTFS support uses the ntfs filesystem type code.
- ISO-9660 and Rock Ridge
- This filesystem is the most common one of CD-ROM, CD-R, and CD-RW discs. It's also sometimes used on recordable DVD media. ISO-9660 comes in three levels. ISO-9660 Level 1 is limited to 8.3 filenames similar to those of FAT; Level 2 adds support for 32-character filenames; and Level 3 also supports 32-character filenames, but changes some internal data structures to make it easier to update an existing filesystem. Linux supports reading all three levels via its iso9660 filesystem type code. An extension to ISO-9660, known as Rock Ridge, supports long filenames and Unix-style ownership and permissions. Windows systems can't handle Rock Ridge extensions, but they don't interfere with Windows' ability to read the underlying ISO-9660 filesystem. Linux's iso9660 driver auto-detects Rock Ridge and uses these extensions if they're available. You can create an ISO-9660 filesystem using the Linux mkisofs command, which takes a wide range of options (consult its manpage for details), and burn it to a recordable disc with cdrecord. Windows systems have no problems reading optical discs created in this way. Various GUI frontends to these tools are also available, such as X-CD-Roast (http://www.xcdroast.org) and K3b (http://www.k3b.org).
- Microsoft created the Joliet filesystem as a way to add long filenames, Unicode filenames, and other features to CD-ROMs. Joliet typically exists side by side with an ISO-9660 filesystem, and it can be ignored by OSs that don't understand it, so, in practice, Joliet works much like the Rock Ridge ISO-9660 extensions. Linux's iso9660 driver automatically detects Joliet and will use the Joliet filesystem if it's present. When both Joliet and Rock Ridge are present, though, Linux favors the Rock Ridge extensions. The Linux mkisofs tool can create an image with Joliet extensions enabled.
- The Universal Disk Format is a next-generation optical disc filesystem. Commercial DVDs usually employ this filesystem, and it's also used on some CD-R and CD-RW discs, particularly those created by Windows packet writing drivers—tools that make the CD-RW drive behave more like a conventional removable magnetic disk than a traditional write-once optical disc. Linux can mount such discs using the udf filesystem type code, but discs so mounted can't be written. The Linux mkisofs utility can create a UDF filesystem alongside an ISO-9660 filesystem, but this feature is considered experimental, at least as of Version 2.0.1.
Any of these filesystems may be used for data exchange between Linux and Windows systems. You can mount them just as you would Linux-native filesystems, but for most, some extra options may be helpful. In particular, most of these filesystems lack Linux ownership and permissions information, so the filesystem driver must fake this information. By default, ownership is given to the user who mounted the disk. This might or might not be appropriate. You can override the setting using various options:
- uid= value
- This option sets the UID number for all the files on the disk.
- gid= value
- This option is similar to the uid option, but it sets the GID number rather than the UID.
- umask= value
- You can set the permission bits that should be removed from all files on a FAT or UDF filesystem with this option.
- dmask= value
- This option works much like umask, but it applies only to directories on FAT filesystems.
- fmask= value
- This option works much like umask, but it applies only to nondirectory files on FAT filesystems.
- mode= value
- This is the ISO-9660 and UDF equivalent to umask, but it accepts a mode to set, rather than permission bits to be removed from the mode.
- This option disables use of Rock Ridge extensions on ISO-9660 filesystems.
- This option disables use of a Joliet filesystem, if one is found.
- exec or noexec
- These options tell the kernel to permit (exec) or not permit (noexec) users to run programs that are marked as executable on a partition. Setting noexec can be a useful security feature to block users running unauthorized code, but it's most useful only if you take other rather extreme measures to prevent users from setting up unauthorized executable programs in other ways.
Frequently, you use these options in /etc/fstab to specify how a filesystem should be mounted:
/dev/hdc /mnt/cdrom auto users,noauto,gid=121,mode=0440 0 0 /dev/fd0 /mnt/floppy auto users,noauto,uid=567,gid=121,umask=0113 0 0
All these entries use the auto filesystem type code, which tells the kernel to auto-detect the filesystem type. All the entries also use the users and noauto filesystem mount options, which let ordinary users mount and unmount disks and tell the system not to attempt to mount the filesystems at boot time, respectively. The first entry uses mod=0440 to set those permissions on mounted CD-ROMs, effectively granting read access to the user who mounts the disc and to everybody in GID 121. The second line sets a specific owner and group for floppies, removes everybody's execute access, and also removes write access for users who aren't UID 567 or GID 121.
Office File Format Compatibility
Office suites are extremely popular tools. Many sites rely on them as their primary workhorse programs. Furthermore, many organizations need to exchange office files with others, in order to collaborate on projects, submit bids for new work, and so on. Thus, file compatibility of office tools is extremely important. Even if you don't need such compatibility for collaboration or other purposes outside of your site, you may need at least minimal compatibility to read old files after migrating a computer or network from Windows to Linux.
Table B-1 summarizes some of the important office suites. In some cases, you may luck out because you might only need a suite that's available across platforms. For instance, if you use StarOffice or OpenOffice.org on Windows, migrating to Linux should be relatively painless, because the Linux versions of these programs use the same file formats. (In fact, OpenOffice.org is the open source variant of the commercial StarOffice, and both use the same file formats.)
One obstacle to Linux migration is the fact that the most ubiquitous office suite today is Microsoft Office, and it's not available for Linux (although it can be run in WINE, Crossover Office, and other emulators). Fortunately, most Linux office suites offer the ability to read Microsoft Office files, although that ability is never perfect. Of these file types, Microsoft Word files are the most difficult to handle. OpenOffice.org and StarOffice provide the best Microsoft Word import ability, although AbiWord is also reasonably good. Others tend to drop a lot of the more advanced formatting features. File exports from native Linux formats to Microsoft Word formats suffer from similar problems. For any of these file types, you should definitely test the import and export abilities. For simple documents, most any program's import/export filters should work adequately. For very complex documents that rely on advanced features, even OpenOffice.org or StarOffice might be inadequate.
Creating and Reading PDF Files
PDF files are extremely important today. Many web sites provide white papers, specification sheets, and other data in PDF form. If you expect to be able to read such files, you must have a PDF-reading program. Likewise, if you want to place such documents on your own web site, you must be able to create these files. Fortunately, Linux has good PDF support, for both creating and reading.
Many Linux PDF-creation tools revolve around Ghostscript (http://www.cs.wisc.edu/~ghost/). This program accepts PostScript input and creates outputs in any of several formats. Most of these formats are bitmap graphics files, but Ghostscript can also create PDF files. Because most Linux programs that can print do so by creating PostScript files and sending them to a print queue, you can usually create a PDF file from a Linux program that can print. One way to do this is to start from a PostScript file on disk (presumably created using an application's "print to disk" feature). The ps2pdf script can pass a PostScript file through Ghostscript with all the correct options to generate a PDF file as output:
$ ps2pdf sample.ps
The result of typing this command is an output file called sample.pdf; ps2pdf generates the output filename based on the input filename. If you like, you can use ps2pdf12, ps2pdf13, or ps2pdf14 instead of ps2pdf. These variants generate output using the Version 1.2, 1.3, or 1.4 PDF specifications, respectively. Most modern readers can handle any of these formats, but if you know the reader used to access the file handles one format or another better, you can force the issue. As of Ghostscript 7.07, the default output of ps2pdf is equivalent to ps2pdf12, but this might change in later versions.
Some programs include explicit PDF-generation support, usually in whatever area handles printing. For instance, Figure B-1 shows KWord's Print dialog box. Rather than select a printer in the Name area, you can select Print to File (PDF), which generates a PDF file. (You must also enter an output filename in a field that's hidden in Figure B-1. Most programs that provide such support rely on Ghostscript; these features merely pass PostScript output through Ghostscript to generate the file you specify.
Another approach to generating PDF files is to link the feature to a printer share. Chapter 4 described this approach with respect to Samba printer shares; you can set up a Samba printer share to pass its input through a custom print command to generate PDF output. You can then call this share from any Samba client, including a Linux system configured to print through the Samba server.
As for reading PDF files, Ghostscript can handle PDF inputs as well as PostScript inputs, so Ghostscript can do the job. Ghostscript by itself isn't exactly a convenient viewer, though. Typically, you'll use a GUI frontend, such as gv (http://wwwthep.physik.uni-mainz.de/~plass/gv/) or KGhostview (a part of KDE). Another alternative is to use Xpdf (http://www.foolabs.com/xpdf/), which is a dedicated PDF viewer that's independent of Ghostview. Another such tool is Adobe's own Acrobat Reader (http://www.adobe.com/products/acrobat/). This program is not open source, but it is freely available. Because Adobe originated the PDF format, Acrobat Reader may be considered the "official" PDF viewer, and it occasionally does a better job with some PDF files, particularly if the creator used was very recent. Unfortunately, Adobe's Linux version is available in binary form only, so you might not be able to run it if you're using an unusual CPU platform.
Managing Cross-Platform Archive Files
Sometimes you must bundle files together, or unbundle files that others have bundled into a carrier archive file. Several classes of files are commonly used for this purpose:
- These files are archives with tar and compressed using compress, gzip, or bzip2. These files most commonly have .tar.Z, .tar.gz, .tar.bz2, .tgz, or .tbz filename extensions. They're most frequently created on Linux or Unix systems, and Linux can handle them just fine. Common Windows archiving programs can usually uncompress these files, but if you know a file will be going to a Windows user, a Zip archive is usually better.
- Zip files
- Zip files are denoted by .zip filename extensions. This file format is most popular on Windows systems, which use tools such as PKZIP (http://www.pkware.com) or InfoZip (http://www.info-zip.org/pub/infozip/) to create them. Both utilities are available in Linux, although only InfoZip is open source. It's usually in a package called zip. This package includes programs called zip and unzip to compress and uncompress files, respectively. Zip files are usually the safest format when sending archive files to Windows users, and they're the format you're most likely to encounter from Windows users.
- CAB files
- Microsoft uses its Cabinet (CAB) file format to distribute software. Chances are you won't need to create a CAB file in Linux, but if you run across a CAB file you want to extract, you can do the job with cabextract (http://www.kyz.uklinux.net/cabextract.php). This might be helpful if you run across some fonts or want to view the instructions that come with a CAB file holding a Windows program before extracting it on a Windows system.
- StuffIt files
- The StuffIt format originated on the Mac OS platform and is usually denoted by a .sit filename extension. You're unlikely to run into StuffIt archives from Windows users, but you might run into such files from Macintosh users. The best way to handle these files in Linux is to use the commercial Stuffit Expander (http://www.stuffit.com). A demo version that can extract files is available for free, but the full version requires payment.
In addition to these major formats, quite a few minor ones exist. Most are supported by Linux programs, so try doing a web search on the filename extension of an unknown archive file and the keyword Linux to locate information on the Linux program. You might also check your Linux distribution's package management system; some have a readily viewed category for archiving utilities.
Some Windows archives are distributed as self-extracting archives. These files have .EXE or .COM extensions, but they really consist of another file format along with a short program to extract the data, all in a single file. These formats are often used for program installers. Self-extracting archives can usually be extracted in Linux using an appropriate Linux program, such as unzip for a self-extracting Zip file archive. The trick is finding the right archiving tool. In theory, the identify might help, but in practice it often fails to be helpful. You may need to simply try one format after another. Most Windows self-extracting archives are either Zip or CAB files, but other formats do crop up from time to time.
Tips for a Smooth Migration
Migrating desktop users from Windows to Linux can be a trying experience. Users are likely to have large numbers of datafiles they rely on. Ensuring that these files aren't lost or damaged can be a tricky proposition. Users must also be trained in the new OS and its applications, and of course the transition period is likely to be chaotic simply because of the number of ongoing changes.
How can you make matters run more smoothly? You can employ several tricks to help minimize the risk of disaster and smooth the transition from Windows to Linux:
- Use backups
- Before doing anything destructive to users' desktop systems, back them up—or at least back up critical user datafiles. (Locating such files may be very challenging; if you can possibly afford it, perform a full backup.) The network backup procedures described in Chapter 14 can be very helpful in performing this backup. When something else goes wrong (and in a big transition, it will), a backup can be a life-saver.
- Use file servers
- You can set up a Samba file server (or a Windows file server) and instruct your users to copy or move all their important files to this server. (You may need to keep an eye on the server to be sure they don't copy their Windows system files and program files, though!) When users are transitioned over to Linux, you can configure the new desktop systems to access the same files, thus minimizing your need to copy user files during the transition process. This can be a useful strategy even if you don't want to use the file server on a long-term basis; create a transition schedule and cycle users' files on and off the temporary file server.
- Use IMAP servers
- Ahead of the transition, you can set up an IMAP server, as described in Chapter 13, to handle mail. Instruct your users to store their mail on the IMAP server, using their Windows mail clients. When users transition to Linux, they'll find all their email files present on the IMAP server, thus minimizing email disruption and obviating the need to copy mailbox files or convert their format. The risk, of course, is that if users don't move their mail files to the IMAP server, those files might be lost.
- Consider personal files and conversions
- Some types of files may need to be converted, copied to new locations, or abandoned. For instance, web browser bookmark files and email address books are likely to require conversion. (You can use Mozilla or Firefox on Windows to convert Internet Explorer bookmarks, then move the bookmarks.html file to Linux.) If you can find command-line utilities to handle such files, you may be able to write a script to handle the most important of these files, or at least create a checklist to help you convert them manually.
- Rotate upgrades
- Rather than try to upgrade the system at a user's desk, install Linux on a computer, swap it with a user's existing machine, install Linux on that machine, and then repeat the process. You should be able to perform the physical machine swap in just a few minutes, minimizing the user's downtime. Of course, you'll have to carefully plan this operation so that users don't receive machines with radically different capabilities than their existing ones—unless of course you want to provide upgrades (or downgrades) to some users. Another problem is in managing users' local datafiles, which may change until the last minute. Using a file server to store such files, as just described, can help with this problem.
- Use Linux emergency systems
- If you plan to migrate existing hardware, use an emergency or demo Linux system, such as Knoppix (http://www.knoppix.org), to test the hardware before wiping the hard disk and installing Linux. Such tools are likely to turn up problems with unsupported video cards or other hardware problems before you get too far into the installation process. If a potential problem looks too tough, you can delay the upgrade on that computer rather than spend time on it in a time-critical period.
- Provide adequate training
- You can't expect the average user to pick up Linux with no trouble. Training is therefore imperative and should be done before users are faced with their new OS.
- Perform test conversions
- Try converting a small number of users in a nondestructive way—say, by setting them up with new computers while leaving their old Windows computers in place, at least temporarily. This practice will enable you to locate potential trouble spots in the conversion, and if this goes badly enough, you can back out.
- New-hire conversions
- You can introduce Linux initially for new users and keep their systems upgraded, but upgrade existing Windows systems less frequently. This practice tends to create a user-driven demand for conversion, particularly among users of older Windows systems. Having users asking to be switched to Linux can be very helpful because you won't be fighting your users on this point.
Generally speaking, you should think through the upgrade process. What tasks are likely to require a lot of time, either on your part or on the part of the users? Can anything be done to minimize this time investment? A little thought and experimentation before you begin can prevent a lot of chaos down the road.
A perennial thorn in the side of Linux desktop use is font handling. In the past, X programs relied exclusively on X's font features (the X core fonts, as they're now known), which were primitive compared to those of Windows or Mac OS. Since 2000, new font tools have appeared (namely, Xft fonts), and they are now used by many of the most popular X-based Linux programs. Although the new systems are easier to use and present fonts that most users find more visually appealing, they add complexity to the overall Linux font-handling system. Thus, you must understand both these font systems. Many programs also provide their own font-handling tools, although most are converging on Xft. Of those that have not yet adopted Xft, OpenOffice.org (and its commercial twin, StarOffice) is the most important.
Linux Font-Handling Systems
Linux provides two major GUI font-handling systems: X core fonts and Xft fonts. In addition, individual X-based programs sometimes employ their own font-handling systems. This profusion of font-rendering tools can lead to some confusion if you're not aware of the differences between these systems, each of which has its own unique quirks.
The oldest X font-handling system is the X core fonts system. X core fonts are server-side fonts, meaning that the X server (the system at which the user sits, in most cases) handles the fonts. X clients (that is, X programs) tell the X server what font to display and at what size, and the X server does the rest.
X core fonts were originally designed with bitmap fonts in mind, meaning that individual characters were designed for display at a specific size in pixels. To support scaleable fonts, which can be resized, multiple bitmap font files are required, one for each size. X servers, including the XFree86 and Xorg-X11 X servers for Linux, ship with several bitmap fonts in a variety of sizes, designed for both 72 dots per inch (dpi) and 100-dpi displays. Most modern fonts, though, use scaleable font (a.k.a. outline font) technologies, in which the font is described in terms of mathematical descriptions of lines and curves. These descriptions provide an outline of a character, which the font renderer can scale to any desired resolution and fill in. The two most common scaleable font formats today are PostScript Type 1 (a.k.a. Adobe Type Manager or ATM) fonts and TrueType fonts. XFree86 has supported both formats since Version 4.0 (before that, it didn't support TrueType fonts), and Xorg-X11 also supports both formats.
Because X core fonts are server-side, relatively little data needs to be transferred between the client and server to display text. This feature can be helpful for remote logins but isn't very important for typical desktop operations.
Some Linux distributions implement X core fonts via a font server , which is a server designed to deliver bitmap font data to X servers. X ships with a font server, xfs, which can deliver bitmap font data from bitmap font files or generated from Type 1 or TrueType fonts. This topic is described in more detail shortly, in Section B.5.2.3.
The X core font system was designed years ago, and in the intervening years, font technology has progressed. X core fonts were readily adapted to some new technologies, such as scaleable fonts, but basic limitations in X core fonts have presented more of a challenge. One of these problems has been the fact that X core fonts can't readily handle more than two colors per font (such as black for the foreground and white for the background). This limitation means that a new font technology known as font smoothing or anti-aliasing was slow to come to Linux. Font smoothing uses shades of gray to deliberately blur fonts. Counter-intuitively, this has the subjective effect of improving the appearance of fonts, because it tends to hide the jagged edges along diagonal lines and curves. Not everybody cares for this effect, but many people do, and font smoothing is a standard part of Windows and Mac OS. Another problem with the X core fonts system has been that installing fonts can be tricky, as described in the next section. Finally, X core fonts were not designed with printing in mind, and coordinating the display and print fonts can be a challenge when using these fonts.
The solution to these problems with X core fonts is the Xft font system. Unlike the X core fonts, Xft fonts are client-side, meaning that they're installed on the same computer as the programs that call them. This fact means that more data may need to be transferred over the network when they're used, but if a program relies on particular fonts, it's easier to guarantee that they'll be available because the user's server configuration is irrelevant. Xft was designed around the FreeType library, which was originally a tool for rendering TrueType fonts. Today, though, Xft supports both TrueType and Type 1 fonts. Xft fonts also support font smoothing, although this feature can be shut off. Xft fonts provide a few more hooks to help with printing, although screen/printer font coordination in Linux has improved more because of extra libraries than because of Xft. Installing Xft fonts is easier than installing X core fonts, as well. However, configuring these fonts requires changing yet another system. In the short term, this has caused increased problems because administrators must manage both X core fonts and Xft fonts. In the long term, Xft fonts are likely to increase in importance, and X core fonts may become so unimportant that their configuration will be trivial. In fact, this may have already happened for some environments. The GNOME and KDE projects have both embraced Xft fonts, as have many other programs, so it's possible you'll see very few or no X core fonts in use on some systems.
In addition to X core fonts and Xft fonts, some individual programs handle their own fonts. Traditionally, word processing programs have done this; however, many Linux word processors have now switched to Xft. A few, though, such as OpenOffice.org and its commercial twin StarOffice, continue to require their own font configuration.
Installing X Core Fonts
Installing X core fonts requires placing font files in directories of your choosing, creating or modifying files in that directory to describe the fonts, and pointing the X server to the fonts. These tasks must be done on the X server computer, so if you use X terminals (as described in Chapter 12), you may need to make these changes on many systems. One way to simplify this task, particularly for a large network, is to use a font server, which places most of the administrative burden on one computer. Some Linux distributions, such as Fedora, Mandrake, and Red Hat, use font servers locally, so you may need to deal with font server configuration even for standalone desktop systems.
Preparing font directories
The first task in X core font configuration is to install the fonts. Part of this task is fairly obvious: you copy font files from some source, such as a commercial font CD-ROM or an Internet font download site, to a directory of your choice. For locally installed fonts, /usr/local/fonts or a subdirectory of that directory is a logical choice. Linux systems usually install their default fonts in /usr/share/fonts, although older distributions used /usr/X11R6/lib/X11/fonts or other locations.
Once the font files are installed, you must create a configuration file that describes the fonts. This file is called fonts.dir and resides in the same directory as the fonts themselves. Its first line contains nothing but a number that denotes the number of fonts described in the configuration file. Subsequent lines have a format that looks deceptively simple:
The filename.ext is the font filename. For TrueType fonts, this ends in .ttf; for Type 1 fonts, it's either .pfa or .pfb. Various bitmap font formats exist, each with its own extension.
The tricky part of the fonts.dir file is the XLFD field, which describes an X Logical Font Descriptor (XLFD). The XLFD consists of multiple fields of its own, separated by dashes (-). These fields contain the name of the font creator, the name of the font, the weight of the font, a code for its slant, numbers relating to its size, and so on. Even if you understand every field, XLFDs can be difficult to read because the fields tend to blur together in the eye. An example of a complete fonts.dir entry looks like this:
As a practical matter, it's usually best to create the fonts.dir file with a helper program. Several such programs exist, each with its own unique qualities:
- This program may not be installed in your distribution, although most distributions do provide it under the package name type1inst or font-tools. Once it's installed, type type1inst in the directory that holds Type 1 fonts. You should see a fonts.dir file appear, along with fonts.scale (which is similar to fonts.dir, but describes only scaleable fonts). This program isn't useful for handling TrueType fonts.
- This program is essentially a TrueType counterpart to type1inst. It's usually delivered in a package called ttmkfdir or freetype-tools. It sends its output to stdout by default, so you must redirect it, as in ttmkfdir > fonts.dir.
- This program ships with Xorg-X11 and XFree86 4.3 and later. It creates a fonts.scale file that describes both TrueType and Type 1 fonts. To create a fonts.dir file, you must type mkfontscale and then either copy this file to fonts.dir or type mkfontdir. This program creates a fonts.dir file from the contents of fonts.scale and information on any bitmap fonts in the directory.
As a general rule, I recommend creating separate directories for each font type you use—Type 1, TrueType, and bitmap or more exotic font formats you install. This practice gives you greater flexibility in the use of programs that generate fonts.dir files.
Setting the X font path
Once you've installed font files, you can move on to editing the X server's configuration file: /etc/X11/XF86Config or /etc/X11/xorg.conf. (This file sometimes appears in /etc rather than /etc/X11.) The XF86Config file controls the XFree86 server, which most distributions abandoned in 2004 because of a licensing change with Version 4.4.0. The xorg.conf file controls Xorg-X11, which is based on the last version of XFree86 prior to the license change, so the two servers are nearly identical, at least as of XFree86 4.4.0 and Xorg-X11 6.7.0 (the first formal release version). Likewise, their configuration files are virtually identical. One important difference, though, is that their default font directories are different.
X looks for fonts in directories in the Files section of XF86Config or xorg.conf. Specifically, the configuration file holds a series of lines that begin with the keyword FontPath, and each line contains a path or other reference in quotes:
FontPath "/usr/share/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/75dpi/" FontPath "tcp/gutenberg:7100" FontPath "unix/:-1"
Most of the entries in this example point to subdirectories of /usr/share/fonts, which is the default location for fonts in Xorg-X11. In an XF86Config file, this location is more likely /usr/X11R6/lib/X11/fonts. In any event, two broad classes of entries may be present:
- Local font directories
- Entries that look like font directory names are just that. X looks in these directories for font configuration files (described shortly) and displays the fonts they contain when programs ask for them. The first entry in the preceding example deserves elaboration, though: the :unscaled code tells X to deliver bitmap fonts from this directory only if they can be delivered at precisely the requested size. For instance, if a program asks for Times at 10 points, and if the directory holds Times at 9 points and 12 points but not at 10 points, X doesn't display Times from this directory. The idea is that a subsequent directory is likely to hold the font at the precisely requested size or in a scaleable form. Later in this list, the same directory appears without the :unscaled qualifier, so if all the other possibilities don't match the font, X delivers a font bitmap that's been scaled from another bitmap. The result is likely to look quite ugly, but it's better than not delivering a font at all.
- Font servers
- The last two examples from the preceding example are font servers. The first of these specifications (tcp/gutenberg:7100) tells X to use a remote computer (gutenberg) via TCP/IP on port 7100. The second entry (unix/:-1) tells the system to use Unix domain sockets to connect to a local font server on port -1. Distributions that use local fonts servers are likely to have XF86Config or xorg.conf files that refer exclusively to such a local font server; they may not refer directly to any font directories.
If your X configuration file refers only to a local font server, you can either add your new font directories directly to the X configuration file or modify your X font server configuration. The latter is likely to be less confusing in the long run because your true font path will be accessible from a single location.
Configuring a font server
If your distribution uses a font server, you might want to modify its configuration rather than the main X configuration file. The standard location for an xfs configuration file is /etc/X11/fs/config. This file contains several lines that set various options, such as whether to bind to TCP ports (which is required for access by other computers). The lines that adjust the font path, though, begin with the keyword catalogue:
catalogue = /usr/share/fonts/75dpi/:unscaled, /usr/share/fonts/misc/, /usr/share/fonts/Type1/, /usr/share/fonts/TTF/, /usr/share/fonts/75dpi/
This example sets the font path identically to the one described earlier, except that it refers to no other font servers. (You should point X servers directly at font servers; don't try to point font servers at other font servers.) The rules for :unscaled references are identical, but the format of the font path is different. In the /etc/X11/fs/config file, the font path is a comma-delimited list that may span multiple lines; the last entry does not end in a comma. Although the entries are often split across lines, they need not be; you can present a single very long font path on one line. Quotes are not placed around individual entries.
Both the main X server and font servers require the same configuration in the font directories—namely a fonts.dir file that describes the font files.
Once you change this configuration, you must restart your X font server. Typically, you can do this by using a SysV startup script:
# /etc/init.d/xfs restart
The system should shut down and restart the font server, but the fonts won't yet be accessible. To use them, you must tell X to reexamine its font path.
Using the fonts
After you change your X font configuration (either via the X server's main configuration file or a font server), you must tell X to use the new fonts. If you've edited your X configuration file, the safest way to do this and to be sure you've made no errors is to shut down X and restart it. On most distributions, logging out of a GUI login will do this job. If you don't want to completely restart X, though, you can type the following commands:
$ xset fp+ /new/font/path $ xset fp rehash
The first of these commands adds a directory to your font path. Be sure to type this directory exactly as you entered it on the FontPath line in your X configuration file. One problem with this approach is that it adds the new font directory to the end of the font path, which may not be where you added it. Thus, results might not exactly match what you'll get when you restart X, particularly if there's overlap in font names.
The second line tells X to reexamine the fonts in its font path, effectively adding the new fonts to the list of available fonts. You should type this command without the previous one if you've modified your X font server configuration and want to use the new fonts that it's now offering.
Modifying the font path while X is running is potentially risky. If you make a mistake, critical fonts might disappear. This can cause programs to hang. In extreme cases, X might crash. Save your work before making such changes and be prepared to log in using some other means (a text-mode console login, SSH from another system, or what have you) to correct any problems that might develop.
Installing Xft Fonts
Compared to installing X core fonts, installing Xft fonts is relatively straightforward. Xft 2.0 and later use a configuration file called /etc/fonts/fonts.conf to control themselves. You shouldn't directly edit this file, however; it can be overwritten in a package upgrade. Instead, Xft sets aside /etc/fonts/local.conf for local changes. To add a font directory to the Xft font path, place this line just above the </fontconfig> line:
Versions of Xft prior to 2.0 used another configuration file, /etc/X11/XftConfig, to control their overall operation. This configuration file is very different from the Xft 2.0 configuration file described here.
This line tells Xft to look in the /usr/local/fonts directory and all its subdirectories for font files. In fact, because Xft looks in subdirectories of the specified font directories means that you may not even need to modify the Xft configuration file at all: simply place your font files in a subdirectory of a directory that's specified in /etc/fonts/fonts.conf. Most Xft configurations list /usr/share/fonts as a directory, so placing new fonts in a subdirectory of that directory should work. Furthermore, most Xft configurations list ~/.fonts as a font directory, meaning that individual users can install fonts themselves by placing them in this directory.
Once the font directories are set, and fonts are placed in them, users can begin using fonts immediately; there's no need to restart X or issue any special commands. There is a modest benefit to using one command, though: fc-cache. If you've installed new fonts in a particular directory, type this command:
# fc-cache /path/to/fonts
The fc-cache command is the main interface to FontConfig, which is responsible for configuring Xft fonts. This command creates a font index file (fonts.cache-1) that's conceptually similar to the X core fonts' fonts.dir. Unlike X core fonts, though, Xft enables users to maintain their own font index files, and if Xft detects that directories on the font path have been updated more recently than their matching index files, FontConfig runs fc-cache in a way that updates users' individual font configuration files (~/.fonts.cache-1). Thus, if you fail to perform this step, users can still access new fonts; however, they may experience slight delays when starting new applications soon after you add fonts, as fc-cache does its job.
Installing Fonts in OpenOffice.org
OpenOffice.org supports its own font-rendering system. As a result, fonts you install as X core fonts or Xft fonts won't appear as options in the OpenOffice.org menus, at least as of OpenOffice.org 1.1.2. (Future versions might switch to supporting Xft.)
OpenOffice.org is the open source twin of StarOffice. These two programs are virtually identical, and both work the same way in terms of font configuration.
OpenOffice.org provides a printer and font administration tool in which you can adjust the program's printer list and install or remove fonts. To do the latter, follow these steps:
- In a command-prompt window, type oopadmin to launch the program. A window entitled Printer Administration should appear.
- Click the Fonts button. A Fonts dialog box should appear, as shown in Figure B-2.
- Click Add in the Fonts dialog box to add new fonts. A dialog box entitled Add Fonts should appear, as shown in Figure B-3.
- Type a path to your fonts in the "Source directory" field or click the "..." button to select a directory using a file selector. If you type the path, wait a few seconds after you finish the path. The system should then populate the top field in the Add Fonts dialog box with font names and filenames.
- Select any and all fonts you want to add by clicking their names in the Add Fonts dialog box.
- Click Add in the Add Fonts dialog box. The system should respond with a report on the number of fonts it added.
- Click Close in the Fonts dialog box, followed by Close in the Printer Administration dialog box.
You can perform these steps as either root or as an ordinary user. If the former, the fonts are installed in the main OpenOffice.org directory; if the latter, they're installed in the user's home directory.
Linux's credentials as a desktop OS are growing. Traditionally deployed as a server, Linux's GUI tools and application programs are improving rapidly, to the point that increasing numbers of organizations are deploying the OS on the desktop as well as in the server room. Doing this requires that you know a bit about Linux desktop applications, starting with the desktop environments available for Linux. Sometimes Linux's ability to run Windows programs (either by itself or with the help of a remote server) is important for Linux desktop deployment. Accessing data from Windows desktop systems and managing fonts are a couple more areas that are important for Linux desktop use.