OpenOffice.org Off the Wall: Fonts of Wisdom
The selection of fonts is central to document design. Knowing how to choose fonts not only affects legibility, but it also reinforces a document's tone and content. Yet, until recently, few Linux users gave font selection much thought. Font installation was esoteric, and the user-base consisted mainly of developers, who generally preferred the markup language approach of delivering content that leaves layout to style sheets and XSLTs.
In the last few years, the push to prepare Linux for the desktop has changed all of that. On both KDE and GNOME, font installation now is as easy to accomplish as it is on any other operating system. In addition, the introduction of office suites such as OpenOffice.org has introduced Linux to software that encourage users to think about format as much as content.
Even if you are not a content-purist, these changes sometimes seem to be a mixed blessing. They not only threaten new users with option anxiety, they also are a major cause of design atrocities. The trouble is, design in general and font selection in particular in an office suite require a rare mixture of skills. On the one hand, successful font selection requires a technical knowledge of both how fonts work and the tools available in the office suite for selecting and manipulating them. On the other hand, it also requires a knowledge of design and of what choices are likely to work in a given set of circumstances. What's more, neither body of knowledge is much good without the other.
What follows is an introduction to some of the basic issues as they apply to Linux and OpenOffice.org: What fonts are available? How are they installed? What tools in OpenOffice.org allow you to make use of them? Most important of all, what do you need to consider when selecting and customizing fonts? A complete answer to even one of these questions could fill a book. However, the brief answers that follow should help you make more informed choices about using fonts. Whether you are using manual overrides or paragraph and character styles, once you can work with fonts effectively, you are one step closer to using the full power of OpenOffice.org.
Linux supports several different font formats. However, despite attempts over the years to introduce new formats, the majority of fonts still are either PostScript (aka Type1 or Adobe) or TrueType.
Postscript, of course, is the printer language created by Adobe Systems. PostScript fonts can be used by a PostScript printer without conversion. Each PostScript font has several files associated with it. The files have the same name, but a different extension:
.afm (Adobe Font Metrics): contains the proportions for each character in the font. Necessary for displaying or printing the font.
.pfb (Printer Binary Font): contains instructions on how to print the font.
.inf and .pfm: Windows-only files. Not needed for use under Linux.
TrueType is a format first introduced on the Mac and later popularized by Windows. In some circles, TrueType fonts still have a bad reputation. This reputation is due partly to the fact that the PostScript printing language did not support TrueType when the format was introduced. Mainly, though, the bad rep is traceable to the fact that many of the first TrueType fonts were poor-quality conversions of PostScript font. Neither concern has much validity today, but the reputation lingers. TrueType fonts include all information about displaying and printing in a single file, with a .ttf extension.
Which format you use is relevant only for installation.The myth persists that TrueType fonts are superior for on-screen display; while that theoretically is true, in practice even the best screen resolutions are too low for any difference to be noticeable. On the other side, because PostScript fonts do not need to be converted when sent to a printer, they might be considered more likely to print exactly as you seem them on screen. And, in fact, PostScript fonts do seem to have fewer problems when you import from OpenOffice.org to .pdf format, PostScript's close cousin. Yet, for the most part, you can choose the font format based on availability and usefulness rather than technical merits.
Fonts used in OpenOffice.org can be installed in two main ways: in the X Window System in general or in OpenOffice.org in particular. In both cases, you should install only the fonts you need. Font files are relatively small in themselves, but collections of several thousand fonts are common, and installing this many fonts would deliver a serious blow to your machine's performance. Better in either case to load or unload fonts as you need them.
The advantage of installing in the X Window System is the fonts are available for all desktop applications, including GNOME, KDE and window managers. The old-fashioned way is to install a font server (for example, xfs and xfstt for TrueType fonts or type1inst for PostScript fonts) Installing any of these font servers may involve editing the XF86Config file. Full instructions for installing are available here.
More recently, the KDE Control Center has included a font installer, while GNOME offers a plug-in to Nautilus called Fontilus. Both offer a graphical installer for fonts comparable to the Adobe Type Manager on Windows or OS X.
The advantage of installing only to OpenOffice.org is the fonts don't drag down general system performance. The brute force method is to copy font files into the /user/fonts directory for your OpenOffice.org installation. Alternatively, you can run spadmin, a utility that runs outside of OpenOffice.org proper and includes the installation of fonts on a printer-by-printer basis.
None of these methods have significant advantages over the others. What matters is not which method you choose but that you use it consistently. Mixing the methods can cause duplicate entries and general confusion.
-- Bruce Byfield (nanday)
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development