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)
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide