Commit | Line | Data |
a0d0e21e |
1 | =head1 NAME |
2 | |
cb1a09d0 |
3 | perlpod - plain old documentation |
a0d0e21e |
4 | |
5 | =head1 DESCRIPTION |
6 | |
7 | A pod-to-whatever translator reads a pod file paragraph by paragraph, |
8 | and translates it to the appropriate output format. There are |
9 | three kinds of paragraphs: |
10 | |
11 | =over 4 |
12 | |
13 | =item * |
14 | |
15 | A verbatim paragraph, distinguished by being indented (that is, |
16 | it starts with space or tab). It should be reproduced exactly, |
17 | with tabs assumed to be on 8-column boundaries. There are no |
18 | special formatting escapes, so you can't italicize or anything |
19 | like that. A \ means \, and nothing else. |
20 | |
21 | =item * |
22 | |
23 | A command. All command paragraphs start with "=", followed by an |
24 | identifier, followed by arbitrary text that the command can |
25 | use however it pleases. Currently recognized commands are |
26 | |
27 | =head1 heading |
28 | =head2 heading |
29 | =item text |
30 | =over N |
31 | =back |
4633a7c4 |
32 | =cut |
cb1a09d0 |
33 | =pod |
c7c9f956 |
34 | =for X |
35 | =begin X |
36 | =end X |
cb1a09d0 |
37 | |
38 | The "=pod" directive does nothing beyond telling the compiler to lay |
39 | off of through the next "=cut". It's useful for adding another |
40 | paragraph to the doc if you're mixing up code and pod a lot. |
41 | |
42 | Head1 and head2 produce first and second level headings, with the text on |
43 | the same paragraph as "=headn" forming the heading description. |
44 | |
45 | Item, over, and back require a little more explanation: Over starts a |
46 | section specifically for the generation of a list using =item commands. At |
47 | the end of your list, use =back to end it. You will probably want to give |
184e9718 |
48 | "4" as the number to =over, as some formatters will use this for indentation. |
cb1a09d0 |
49 | This should probably be a default. Note also that there are some basic rules |
50 | to using =item: don't use them outside of an =over/=back block, use at least |
51 | one inside an =over/=back block, you don't _have_ to include the =back if |
52 | the list just runs off the document, and perhaps most importantly, keep the |
53 | items consistent: either use "=item *" for all of them, to produce bullets, |
54 | or use "=item 1.", "=item 2.", etc., to produce numbered lists, or use |
55 | "=item foo", "=item bar", etc., i.e., things that looks nothing like bullets |
56 | or numbers. If you start with bullets or numbers, stick with them, as many |
184e9718 |
57 | formatters use the first =item type to decide how to format the list. |
cb1a09d0 |
58 | |
c7c9f956 |
59 | For and begin/end let you include sections that are not interpreted as pod |
60 | text, but in a format that a particular formatter is looking for. A |
61 | formatter that can utilize that format will use the section, otherwise it |
62 | will be completely ignored. "=for" specifies that the entire paragraph |
63 | should is in the format indicated by the first word after "=for", like this: |
64 | |
65 | =for html <br> |
66 | <p> This is a raw HTML paragraph </p> |
67 | |
68 | The paired commands "=begin" and "=end" work very similarly to =for, but |
69 | instead of only accepting a single paragraph, all text from =begin to a |
70 | paragraph with a matching =end are treated as a particular format. |
71 | |
72 | Here are some examples of how to use these: |
73 | |
74 | =begin html |
a6006777 |
75 | |
c7c9f956 |
76 | <br>Figure 1.<IMG SRC="figure1.png"><br> |
a6006777 |
77 | |
c7c9f956 |
78 | =end html |
a6006777 |
79 | |
c7c9f956 |
80 | =begin text |
a6006777 |
81 | |
c7c9f956 |
82 | --------------- |
83 | | foo | |
84 | | bar | |
85 | --------------- |
a6006777 |
86 | |
c7c9f956 |
87 | ^^^^ Figure 1. ^^^^ |
a6006777 |
88 | |
c7c9f956 |
89 | =end text |
90 | |
91 | Some format names that formatters currently are known to accept include |
92 | "roff", "man", "latex", "tex", "text", and "html". (Some formatters will |
93 | treat some of these as synonyms.) |
94 | |
cb1a09d0 |
95 | And don't forget, when using any command, that that command lasts up until |
96 | the end of the B<paragraph>, not the line. Hence in the examples below, you |
184e9718 |
97 | can see the blank lines after each command to end its paragraph. |
cb1a09d0 |
98 | |
99 | Some examples of lists include: |
100 | |
101 | =over 4 |
102 | |
103 | =item * |
104 | |
105 | First item |
106 | |
107 | =item * |
108 | |
109 | Second item |
110 | |
111 | =back |
112 | |
113 | =over 4 |
114 | |
115 | =item Foo() |
116 | |
117 | Description of Foo function |
118 | |
119 | =item Bar() |
120 | |
121 | Description of Bar function |
122 | |
123 | =back |
a0d0e21e |
124 | |
125 | =item * |
126 | |
127 | An ordinary block of text. It will be filled, and maybe even |
128 | justified. Certain interior sequences are recognized both |
129 | here and in commands: |
130 | |
131 | I<text> italicize text, used for emphasis or variables |
132 | B<text> embolden text, used for switches and programs |
133 | S<text> text contains non-breaking spaces |
134 | C<code> literal code |
135 | L<name> A link (cross reference) to name |
5f05dabc |
136 | L<name> manual page |
137 | L<name/ident> item in manual page |
138 | L<name/"sec"> section in other manual page |
139 | L<"sec"> section in this manual page |
a0d0e21e |
140 | (the quotes are optional) |
cb1a09d0 |
141 | L</"sec"> ditto |
a0d0e21e |
142 | F<file> Used for filenames |
cb1a09d0 |
143 | X<index> An index entry |
a0d0e21e |
144 | Z<> A zero-width character |
c7c9f956 |
145 | E<escape> A named character (very similar to HTML escapes) |
1294c5d8 |
146 | E<lt> A literal < |
147 | E<gt> A literal > |
148 | (these are optional except in other interior |
149 | sequences and when preceded by a capital letter) |
c7c9f956 |
150 | E<n> Character number n (probably in ASCII) |
7f3dfc00 |
151 | E<html> Some non-numeric HTML entity, such |
152 | as E<Agrave> |
a0d0e21e |
153 | |
3141265f |
154 | =back |
155 | |
a0d0e21e |
156 | That's it. The intent is simplicity, not power. I wanted paragraphs |
157 | to look like paragraphs (block format), so that they stand out |
158 | visually, and so that I could run them through fmt easily to reformat |
159 | them (that's F7 in my version of B<vi>). I wanted the translator (and not |
160 | me) to worry about whether " or ' is a left quote or a right quote |
5f05dabc |
161 | within filled text, and I wanted it to leave the quotes alone, dammit, in |
a0d0e21e |
162 | verbatim mode, so I could slurp in a working program, shift it over 4 |
163 | spaces, and have it print out, er, verbatim. And presumably in a |
164 | constant width font. |
165 | |
166 | In particular, you can leave things like this verbatim in your text: |
167 | |
168 | Perl |
169 | FILEHANDLE |
170 | $variable |
171 | function() |
172 | manpage(3r) |
173 | |
174 | Doubtless a few other commands or sequences will need to be added along |
175 | the way, but I've gotten along surprisingly well with just these. |
176 | |
177 | Note that I'm not at all claiming this to be sufficient for producing a |
178 | book. I'm just trying to make an idiot-proof common source for nroff, |
179 | TeX, and other markup languages, as used for online documentation. |
cb1a09d0 |
180 | Translators exist for B<pod2man> (that's for nroff(1) and troff(1)), |
181 | B<pod2html>, B<pod2latex>, and B<pod2fm>. |
a0d0e21e |
182 | |
4633a7c4 |
183 | =head1 Embedding Pods in Perl Modules |
184 | |
185 | You can embed pod documentation in your Perl scripts. Start your |
186 | documentation with a =head1 command at the beg, and end it with |
187 | an =cut command. Perl will ignore the pod text. See any of the |
cb1a09d0 |
188 | supplied library modules for examples. If you're going to put |
189 | your pods at the end of the file, and you're using an __END__ |
190 | or __DATA__ cut mark, make sure to put a blank line there before |
191 | the first pod directive. |
192 | |
193 | __END__ |
194 | |
195 | =head1 NAME |
196 | |
197 | modern - I am a modern module |
198 | |
199 | If you had not had that blank line there, then the translators wouldn't |
200 | have seen it. |
201 | |
1294c5d8 |
202 | =head1 Common Pod Pitfalls |
203 | |
204 | =over 4 |
205 | |
206 | =item * |
207 | |
208 | Pod translators usually will require paragraphs to be separated by |
209 | completely empty lines. If you have an apparently blank line with |
210 | some spaces on it, this can cause odd formatting. |
211 | |
212 | =item * |
213 | |
214 | Translators will mostly add wording around a LE<lt>E<gt> link, so that |
215 | C<LE<lt>foo(1)E<gt>> becomes "the I<foo>(1) manpage", for example (see |
216 | B<pod2man> for details). Thus, you shouldn't write things like C<the |
217 | LE<lt>fooE<gt> manpage>, if you want the translated document to read |
218 | sensibly. |
219 | |
220 | =item * |
221 | |
222 | The script F<pod/checkpods.PL> in the Perl source distribution |
223 | provides skeletal checking for lines that look blank but aren't |
224 | B<only>, but is there as a placeholder until someone writes |
225 | Pod::Checker. The best way to check your pod is to pass it through |
226 | one or more translators and proofread the result, or print out the |
227 | result and proofread that. Some of the problems found may be bugs in |
228 | the translators, which you may or may not wish to work around. |
229 | |
230 | =back |
231 | |
cb1a09d0 |
232 | =head1 SEE ALSO |
233 | |
234 | L<pod2man> and L<perlsyn/"PODs: Embedded Documentation"> |
4633a7c4 |
235 | |
cb1a09d0 |
236 | =head1 AUTHOR |
a0d0e21e |
237 | |
238 | Larry Wall |
239 | |