As you are hopefully beginning to see, troff provides you all the mechanisms you need for complete control over your document's format. Unfortunately, this is often more control than you need. Writing documents using bare troff, while possible, can be quite painful. It is very much like programming in assembly language: you have complete control, and when the result works it works really well, but there is an awful lot of detail to keep track of, and it can be tedious and difficult.
To make it easier for regular users to manage the detail, troff allows you to define macros. A macro is like a subroutine in a programming language. You can group commands together to perform a larger task, and use the macro name, instead of writing out the entire sequence of commands each time.
Consider starting a new paragraph. You have to do the following tasks:
1. See if there is room left on the page for at least two lines of text.
2. Skip a space after the last paragraph.
3. Indent the first line of text by 1/2 an inch.
You could write the commands to do this over and over again. But that is (a) tedious, (b) a hassle to update if you change how you do paragraphing. Instead, you can define a macro, say .P, to do this for you.
.de P \" DEfine paragraph macro .ne 3 \" we NEed at least three lines .sp \" SPace down one line .ti .5i \" Temporary Indent .5 inches .. \" end the macro definition
Then, in your text, you just put .P on a line by itself wherever you want a paragraph.
.ds LX the Linux Operating System .ds LJ \fILinux Journal\fP If you are new to \*(LX, then you should subscribe to \*(LJ. It covers \*(LX in great detail, month after month. .P And even if you are an experienced user of \*(LX, \*(LJ will bring you valuable tips and tricks to keep your Linux system up and running.
One of the less attractive features of standard troff is that command, macro, string, and register names are limited to no more than two characters. Fortunately, groff allows longer names, with a different syntax for accessing them. In fact, groff has many nice extensions over troff, making the task of writing macro packages considerably easier. The extensions are documented in the gtroff(1) man page.
There are a number of popular troff macro packages. Using them is like programming in FORTRAN; it beats the heck out of Assembly Language, but it's not as nice as C or Modula-3.
The common macro packages are:
-ms - Manuscript macros. Originated in V7, popular on Berkeley Unix.
-man - Manual Page macros.
-mm - Memorandum Macros. Very powerful macros, popular on System V.
-me - Berkeley Technical Paper macros. An ugly package.
-mdoc - The new Document Macros from Berkeley.
-mandoc - A package that figures out dynamically if you want -man or -mdoc.
groff will support these directly if you have them, particularly using the -C compatibility mode option. It also has its own version of many of these packages.
The -ms and -mm are the most portable packages to use. -mm has many more features than -ms, thus making it harder to learn. In the long run though, the effort is worth it, because you can do so much.
Over the years, it was found that macros helped, but that there were some things that were just too difficult to do in bare troff, even with macro packages. The approach that was developed was to write a “little language” that solved a particular task, and to pre-process the language into raw troff. The common pre-processors are:
tbl - formats tables
eqn - formats equations
pic - formats pictures (diagrams)
grap - formats graphs
As an example, here is part of a table from a reference card I worked on:
.TS tab(~); lfB l lfB l. abs~absolute value~int~integer part acos~arc cosine~log~natural logarithm asin~arc sine~sin~sine atan~arc tangent~sinh~hyperbolic sine cos~cosine~sqrt~square root cosh~hyperbolic cosine~tan~tangent .TE
We'll explain it line by line. First, tbl only looks at lines between .TS (table start) and .TE (table end). Everything else is left alone. This makes it easy to use tbl in a pipeline with the other preprocessors. The first line sets the tab character to ~. Normally, tabs in the input separate each column of the table. For this table, a ~ is used to make it easier to mark off the columns.
Then, for each line of data in the table, you provide a line that describes the layout information. l means left justified, r means right justified, and c means centered. All the columns in this table are left justified. The first and third columns also use a different font (the f). Here, they are using the bold font.
In this example, there is only one control line, so it is applied to all the data lines. For more complicated tables, you have one control line per data line, with the last control line applying to any remaining data lines.
The other preprocessors are similar in functionality. grap is actually a preprocessor for pic.
Typically, the commands are used in a pipeline:
grap doc.tr pic tbl eqn troff -mm -Tps > doc.ps
The actual usage will vary from machine to machine; we'll see below how to run groff.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
3 hours 3 min ago
- Yeah, user namespaces are
4 hours 19 min ago
- Cari Uang
7 hours 50 min ago
- user namespaces
10 hours 44 min ago
11 hours 10 min ago
- One advantage with VMs
13 hours 38 min ago
- about info
14 hours 11 min ago
14 hours 12 min ago
14 hours 13 min ago
14 hours 15 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?