1Pod::Simple::SubclassingP(e3rplm)Programmers ReferencePGoudi:d:eSimple::Subclassing(3pm)
2
6 Pod::Simple::Subclassing -- write a formatter as a Pod::Simple subclass
7
9 package Pod::SomeFormatter;
10 use Pod::Simple;
11 @ISA = qw(Pod::Simple);
12 $VERSION = '1.01';
13 use strict;
14 sub _handle_element_start {
16 my($parser, $element_name, $attr_hash_r) = @_;
17 ...
18 }
19 sub _handle_element_end {
21 my($parser, $element_name) = @_;
22 ...
23 }
24 sub _handle_text {
26 my($parser, $text) = @_;
27 ...
28 }
29 1;
30
32 This document is about using Pod::Simple to write a Pod processor,
33 generally a Pod formatter. If you just want to know about using an
34 existing Pod formatter, instead see its documentation and see also the
35 docs in Pod::Simple.
36 The zeroeth step in writing a Pod formatter is to make sure that there
38 isn't already a decent one in CPAN. See <http://search.cpan.org/>, and
39 run a search on the name of the format you want to render to. Also
40 consider joining the Pod People list
41 <http://lists.perl.org/showlist.cgi?name=pod-people> and asking whether
42 anyone has a formatter for that format -- maybe someone cobbled one
43 together but just hasn't released it.
44 The first step in writing a Pod processor is to read perlpodspec, which
46 contains notes information on writing a Pod parser (which has been
47 largely taken care of by Pod::Simple), but also a lot of requirements
48 and recommendations for writing a formatter.
49 The second step is to actually learn the format you're planning to
51 format to -- or at least as much as you need to know to represent Pod,
52 which probably isn't much.
53 The third step is to pick which of Pod::Simple's interfaces you want to
55 use -- the basic interface via Pod::Simple or Pod::Simple::Methody is
56 event-based, sort of like HTML::Parser's interface, or sort of like
57 XML::Parser's "Handlers" interface), but Pod::Simple::PullParser
58 provides a token-stream interface, sort of like HTML::TokeParser's
59 interface; Pod::Simple::SimpleTree provides a simple tree interface,
60 rather like XML::Parser's "Tree" interface. Users familiar with XML-
61 handling will find one of these styles relatively familiar; but if you
62 would be even more at home with XML, there are classes that produce an
63 XML representation of the Pod stream, notably
64 Pod::Simple::XMLOutStream; you can feed the output of such a class to
65 whatever XML parsing system you are most at home with.
66 The last step is to write your code based on how the events (or tokens,
68 or tree-nodes, or the XML, or however you're parsing) will map to
69 constructs in the output format. Also sure to consider how to escape
70 text nodes containing arbitrary text, and also what to do with text
71 nodes that represent preformatted text (from verbatim sections).
72
74 TODO intro... mention that events are supplied for implicits, like for
75 missing >'s
76 In the following section, we use XML to represent the event structure
78 associated with a particular construct. That is, TODO
79 "$parser->_handle_element_start( I<element_name>, I<attr_hashref> )"
81 "$parser->_handle_element_end( I<element_name> )"
82 "$parser->_handle_text( I<text_string> )"
83 TODO describe
85 events with an element_name of Document
87 Parsing a document produces this event structure:
88 <Document start_line="543">
90 ...all events...
91 </Document>
92 The value of the start_line attribute will be the line number of
94 the first Pod directive in the document.
95 If there is no Pod in the given document, then the event structure
97 will be this:
98 <Document contentless="1" start_line="543">
100 </Document>
101 In that case, the value of the start_line attribute will not be
103 meaningful; under current implementations, it will probably be the
104 line number of the last line in the file.
105 events with an element_name of Para
107 Parsing a plain (non-verbatim, non-directive, non-data) paragraph
108 in a Pod document produces this event structure:
109 <Para start_line="543">
111 ...all events in this paragraph...
112 </Para>
113 The value of the start_line attribute will be the line number of
115 the start of the paragraph.
116 For example, parsing this paragraph of Pod:
118 The value of the I<start_line> attribute will be the
120 line number of the start of the paragraph.
121 produces this event structure:
123 <Para start_line="129">
125 The value of the
126 <I>
127 start_line
128 </I>
129 attribute will be the line number of the first Pod directive
130 in the document.
131 </Para>
132 events with an element_name of B, C, F, or I.
134 Parsing a B<...> formatting code (or of course any of its
135 semantically identical syntactic variants B<< ... >>, or
136 B<<<< ... >>>>, etc.) produces this event structure:
137 <B>
139 ...stuff...
140 </B>
141 Currently, there are no attributes conveyed.
143 Parsing C, F, or I codes produce the same structure, with only a
145 different element name.
146 If your parser object has been set to accept other formatting
148 codes, then they will be presented like these B/C/F/I codes --
149 i.e., without any attributes.
150 events with an element_name of S
152 Normally, parsing an S<...> sequence produces this event structure,
153 just as if it were a B/C/F/I code:
154 <S>
156 ...stuff...
157 </S>
158 However, Pod::Simple (and presumably all derived parsers) offers
160 the "nbsp_for_S" option which, if enabled, will suppress all S
161 events, and instead change all spaces in the content to non-
162 breaking spaces. This is intended for formatters that output to a
163 format that has no code that means the same as S<...>, but which
164 has a code/character that means non-breaking space.
165 events with an element_name of X
167 Normally, parsing an X<...> sequence produces this event structure,
168 just as if it were a B/C/F/I code:
169 <X>
171 ...stuff...
172 </X>
173 However, Pod::Simple (and presumably all derived parsers) offers
175 the "nix_X_codes" option which, if enabled, will suppress all X
176 events and ignore their content. For formatters/processors that
177 don't use X events, this is presumably quite useful.
178 events with an element_name of L
180 Because the L<...> is the most complex construct in the language,
181 it should not surprise you that the events it generates are the
182 most complex in the language. Most of complexity is hidden away in
183 the attribute values, so for those of you writing a Pod formatter
184 that produces a non-hypertextual format, you can just ignore the
185 attributes and treat an L event structure like a formatting element
186 that (presumably) doesn't actually produce a change in formatting.
187 That is, the content of the L event structure (as opposed to its
188 attributes) is always what text should be displayed.
189 There are, at first glance, three kinds of L links: URL, man, and
191 pod.
192 When a L<some_url> code is parsed, it produces this event
194 structure:
195 <L content-implicit="yes" to="that_url" type="url">
197 that_url
198 </L>
199 The "type="url"" attribute is always specified for this type of L
201 code.
202 For example, this Pod source:
204 L<http://www.perl.com/CPAN/authors/>
206 produces this event structure:
208 <L content-implicit="yes" to="http://www.perl.com/CPAN/authors/" type="url">
210 http://www.perl.com/CPAN/authors/
211 </L>
212 When a L<manpage(section)> code is parsed (and these are fairly
214 rare and not terribly useful), it produces this event structure:
215 <L content-implicit="yes" to="manpage(section)" type="man">
217 manpage(section)
218 </L>
219 The "type="man"" attribute is always specified for this type of L
221 code.
222 For example, this Pod source:
224 L<crontab(5)>
226 produces this event structure:
228 <L content-implicit="yes" to="crontab(5)" type="man">
230 crontab(5)
231 </L>
232 In the rare cases where a man page link has a specified, that text
234 appears in a section attribute. For example, this Pod source:
235 L<crontab(5)/"ENVIRONMENT">
237 will produce this event structure:
239 <L content-implicit="yes" section="ENVIRONMENT" to="crontab(5)" type="man">
241 "ENVIRONMENT" in crontab(5)
242 </L>
243 In the rare case where the Pod document has code like
245 L<sometext|manpage(section)>, then the sometext will appear as the
246 content of the element, the manpage(section) text will appear only
247 as the value of the to attribute, and there will be no
248 "content-implicit="yes"" attribute (whose presence means that the
249 Pod parser had to infer what text should appear as the link text --
250 as opposed to cases where that attribute is absent, which means
251 that the Pod parser did not have to infer the link text, because
252 that L code explicitly specified some link text.)
253 For example, this Pod source:
255 L<hell itself!|crontab(5)>
257 will produce this event structure:
259 <L to="crontab(5)" type="man">
261 hell itself!
262 </L>
263 The last type of L structure is for links to/within Pod documents.
265 It is the most complex because it can have a to attribute, or a
266 section attribute, or both. The "type="pod"" attribute is always
267 specified for this type of L code.
268 In the most common case, the simple case of a L<podpage> code
270 produces this event structure:
271 <L content-implicit="yes" to="Net::Ping" type="pod">
273 podpage
274 </L>
275 For example, this Pod source:
277 L<Net::Ping>
279 produces this event structure:
281 <L content-implicit="yes" to="Net::Ping" type="pod">
283 Net::Ping
284 </L>
285 In cases where there is link-text explicitly specified, it is to be
287 found in the content of the element (and not the attributes), just
288 as with the L<sometext|manpage(section)> case discussed above. For
289 example, this Pod source:
290 L<Perl Error Messages|perldiag>
292 produces this event structure:
294 <L to="perldiag" type="pod">
296 Perl Error Messages
297 </L>
298 In cases of links to a section in the current Pod document, there
300 is a section attribute instead of a to attribute. For example,
301 this Pod source:
302 L</"Member Data">
304 produces this event structure:
306 <L content-implicit="yes" section="Member Data" type="pod">
308 "Member Data"
309 </L>
310 As another example, this Pod source:
312 L<the various attributes|/"Member Data">
314 produces this event structure:
316 <L section="Member Data" type="pod">
318 the various attributes
319 </L>
320 In cases of links to a section in a different Pod document, there
322 are both a section attribute and a to attribute. For example, this
323 Pod source:
324 L<perlsyn/"Basic BLOCKs and Switch Statements">
326 produces this event structure:
328 <L content-implicit="yes" section="Basic BLOCKs and Switch Statements" to="perlsyn" type="pod">
330 "Basic BLOCKs and Switch Statements" in perlsyn
331 </L>
332 As another example, this Pod source:
334 L<SWITCH statements|perlsyn/"Basic BLOCKs and Switch Statements">
336 produces this event structure:
338 <L section="Basic BLOCKs and Switch Statements" to="perlsyn" type="pod">
340 SWITCH statements
341 </L>
342 Incidentally, note that we do not distinguish between these
344 syntaxes:
345 L</"Member Data">
347 L<"Member Data">
348 L</Member Data>
349 L<Member Data> [deprecated syntax]
350 That is, they all produce the same event structure, namely:
352 <L content-implicit="yes" section="Member Data" type="pod">
354 "Member Data"
355 </L>
356 events with an element_name of E or Z
358 While there are Pod codes E<...> and Z<>, these do not produce any
359 E or Z events -- that is, there are no such events as E or Z.
360 events with an element_name of Verbatim
362 When a Pod verbatim paragraph (AKA "codeblock") is parsed, it
363 produces this event structure:
364 <Verbatim start_line="543" xml:space="preserve">
366 ...text...
367 </Verbatim>
368 The value of the start_line attribute will be the line number of
370 the first line of this verbatim block. The xml:space attribute is
371 always present, and always has the value "preserve".
372 The text content will have tabs already expanded.
374 events with an element_name of head1 .. head4
376 When a "=head1 ..." directive is parsed, it produces this event
377 structure:
378 <head1>
380 ...stuff...
381 </head1>
382 For example, a directive consisting of this:
384 =head1 Options to C<new> et al.
386 will produce this event structure:
388 <head1 start_line="543">
390 Options to
391 <C>
392 new
393 </C>
394 et al.
395 </head1>
396 "=head2" thru "=head4" directives are the same, except for the
398 element names in the event structure.
399 events with an element_name of over-bullet
401 When an "=over ... =back" block is parsed where the items are a
402 bulletted list, it will produce this event structure:
403 <over-bullet indent="4" start_line="543">
405 <item-bullet start_line="545">
406 ...Stuff...
407 </item-bullet>
408 ...more item-bullets...
409 </over-bullet>
410 The value of the indent attribute is whatever value is after the
412 "=over" directive, as in "=over 8". If no such value is specified
413 in the directive, then the indent attribute has the value "4".
414 For example, this Pod source:
416 =over
418 =item *
420 Stuff
422 =item *
424 Bar I<baz>!
426 =back
428 produces this event structure:
430 <over-bullet indent="4" start_line="10">
432 <item-bullet start_line="12">
433 Stuff
434 </item-bullet>
435 <item-bullet start_line="14">
436 Bar <I>baz</I>!
437 </item-bullet>
438 </over-bullet>
439 events with an element_name of over-number
441 When an "=over ... =back" block is parsed where the items are a
442 numbered list, it will produce this event structure:
443 <over-number indent="4" start_line="543">
445 <item-number number="1" start_line="545">
446 ...Stuff...
447 </item-number>
448 ...more item-number...
449 </over-bullet>
450 This is like the "over-bullet" event structure; but note that the
452 contents are "item-number" instead of "item-bullet", and note that
453 they will have a "number" attribute, which some
454 formatters/processors may ignore (since, for example, there's no
455 need for it in HTML when producing an "<UL><LI>...</LI>...</UL>"
456 structure), but which any processor may use.
457 Note that the values for the number attributes of "item-number"
459 elements in a given "over-number" area will start at 1 and go up by
460 one each time. If the Pod source doesn't follow that order (even
461 though it really should should!), whatever numbers it has will be
462 ignored (with the correct values being put in the number
463 attributes), and an error message might be issued to the user.
464 events with an element_name of over-text
466 These events are are somewhat unlike the other over-* structures,
467 as far as what their contents are. When an "=over ... =back" block
468 is parsed where the items are a list of text "subheadings", it will
469 produce this event structure:
470 <over-text indent="4" start_line="543">
472 <item-text>
473 ...stuff...
474 </item-text>
475 ...stuff (generally Para or Verbatim elements)...
476 <item-text>
477 ...more item-text and/or stuff...
478 </over-text>
479 The indent attribute is as with the other over-* events.
481 For example, this Pod source:
483 =over
485 =item Foo
487 Stuff
489 =item Bar I<baz>!
491 Quux
493 =back
495 produces this event structure:
497 <over-text indent="4" start_line="20">
499 <item-text start_line="22">
500 Foo
501 </item-text>
502 <Para start_line="24">
503 Stuff
504 </Para>
505 <item-text start_line="26">
506 Bar
507 <I>
508 baz
509 </I>
510 !
511 </item-text>
512 <Para start_line="28">
513 Quux
514 </Para>
515 </over-text>
516 events with an element_name of over-block
518 These events are are somewhat unlike the other over-* structures,
519 as far as what their contents are. When an "=over ... =back" block
520 is parsed where there are no items, it will produce this event
521 structure:
522 <over-block indent="4" start_line="543">
524 ...stuff (generally Para or Verbatim elements)...
525 </over-block>
526 The indent attribute is as with the other over-* events.
528 For example, this Pod source:
530 =over
532 For cutting off our trade with all parts of the world
534 For transporting us beyond seas to be tried for pretended offenses
536 He is at this time transporting large armies of foreign mercenaries to
538 complete the works of death, desolation and tyranny, already begun with
539 circumstances of cruelty and perfidy scarcely paralleled in the most
540 barbarous ages, and totally unworthy the head of a civilized nation.
541 =cut
543 will produce this event structure:
545 <over-block indent="4" start_line="2">
547 <Para start_line="4">
548 For cutting off our trade with all parts of the world
549 </Para>
550 <Para start_line="6">
551 For transporting us beyond seas to be tried for pretended offenses
552 </Para>
553 <Para start_line="8">
554 He is at this time transporting large armies of [...more text...]
555 </Para>
556 </over-block>
557 events with an element_name of item-bullet
559 See "events with an element_name of over-bullet", above.
560 events with an element_name of item-number
562 See "events with an element_name of over-number", above.
563 events with an element_name of item-text
565 See "events with an element_name of over-text", above.
566 events with an element_name of for
568 TODO...
569 events with an element_name of Data
571 TODO...
572
574 Pod::Simple provides a lot of methods that aren't generally interesting
575 to the end user of an existing Pod formatter, but some of which you
576 might find useful in writing a Pod formatter. They are listed below.
577 The first several methods (the accept_* methods) are for declaring the
578 capabilites of your parser, notably what "=for targetname" sections
579 it's interested in, what extra N<...> codes it accepts beyond the ones
580 described in the perlpod.
581 "$parser->accept_targets( I<SOMEVALUE> )"
583 As the parser sees sections like:
584 =for html <img src="fig1.jpg">
586 or
588 =begin html
590 <img src="fig1.jpg">
592 =end html
594 ...the parser will ignore these sections unless your subclass has
596 specified that it wants to see sections targetted to "html" (or
597 whatever the formatter name is).
598 If you want to process all sections, even if they're not targetted
600 for you, call this before you start parsing:
601 $parser->accept_targets('*');
603 "$parser->accept_targets_as_text( I<SOMEVALUE> )"
605 This is like accept_targets, except that it specifies also that the
606 content of sections for this target should be treated as Pod text
607 even if the target name in "=for targetname" doesn't start with a
608 ":".
609 At time of writing, I don't think you'll need to use this.
611 "$parser->accept_codes( I<Codename>, I<Codename>... )"
613 This tells the parser that you accept additional formatting codes,
614 beyond just the standard ones (I B C L F S X, plus the two weird
615 ones you don't actually see in the parse tree, Z and E). For
616 example, to also accept codes "N", "R", and "W":
617 $parser->accept_codes( qw( N R W ) );
619 TODO: document how this interacts with =extend, and long element
621 names
622 "$parser->accept_directive_as_data( I<directive_name> )"
624 "$parser->accept_directive_as_verbatim( I<directive_name> )"
625 "$parser->accept_directive_as_processed( I<directive_name> )"
626 In the unlikely situation that you need to tell the parser that you
627 will accept additional directives ("=foo" things), you need to
628 first set the parset to treat its content as data (i.e., not really
629 processed at all), or as verbatim (mostly just expanding tabs), or
630 as processed text (parsing formatting codes like B<...>).
631 For example, to accept a new directive "=method", you'd presumably
633 use:
634 $parser->accept_directive_as_processed("method");
636 so that you could have Pod lines like:
638 =method I<$whatever> thing B<um>
640 Making up your own directives breaks compatibility with other Pod
642 formatters, in a way that using "=for target ..." lines doesn't;
643 however, you may find this useful if you're making a Pod superset
644 format where you don't need to worry about compatibility.
645 "$parser->nbsp_for_S( I<BOOLEAN> );"
647 Setting this attribute to a true value (and by default it is false)
648 will turn "S<...>" sequences into sequences of words separated by
649 "\xA0" (non-breaking space) characters. For example, it will take
650 this:
651 I like S<Dutch apple pie>, don't you?
653 and treat it as if it were:
655 I like DutchE<nbsp>appleE<nbsp>pie, don't you?
657 This is handy for output formats that don't have anything quite
659 like an "S<...>" code, but which do have a code for non-breaking
660 space.
661 There is currently no method for going the other way; but I can
663 probably provide one upon request.
664 "$parser->version_report()"
666 This returns a string reporting the $VERSION value from your module
667 (and its classname) as well as the $VERSION value of Pod::Simple.
668 Note that perlpodspec requires output formats (wherever possible)
669 to note this detail in a comment in the output format. For
670 example, for some kind of SGML output format:
671 print OUT "<!-- \n", $parser->version_report, "\n -->";
673 "$parser->pod_para_count()"
675 This returns the count of Pod paragraphs seen so far.
676 "$parser->line_count()"
678 This is the current line number being parsed. But you might find
679 the "line_number" event attribute more accurate, when it is
680 present.
681 "$parser->nix_X_codes( I<SOMEVALUE> )"
683 This attribute, when set to a true value (and it is false by
684 default) ignores any "X<...>" sequences in the document being
685 parsed. Many formats don't actually use the content of these
686 codes, so have no reason to process them.
687 "$parser->merge_text( I<SOMEVALUE> )"
689 This attribute, when set to a true value (and it is false by
690 default) makes sure that only one event (or token, or node) will be
691 created for any single contiguous sequence of text. For example,
692 consider this somewhat contrived example:
693 I just LOVE Z<>hotE<32>apple pie!
695 When that is parsed and events are about to be called on it, it may
697 actually seem to be four different text events, one right after
698 another: one event for "I just LOVE ", one for "hot", one for " ",
699 and one for "apple pie!". But if you have merge_text on, then
700 you're guaranteed that it will be fired as one text event: "I just
701 LOVE hot apple pie!".
702 "$parser->code_handler( I<CODE_REF> )"
704 This specifies code that should be called when a code line is seen
705 (i.e., a line outside of the Pod). Normally this is undef, meaning
706 that no code should be called. If you provide a routine, it should
707 start out like this:
708 sub get_code_line { # or whatever you'll call it
710 my($line, $line_number, $parser) = @_;
711 ...
712 }
713 Note, however, that sometimes the Pod events aren't processed in
715 exactly the same order as the code lines are -- i.e., if you have a
716 file with Pod, then code, then more Pod, sometimes the code will be
717 processed (via whatever you have code_handler call) before the all
718 of the preceding Pod has been processed.
719 "$parser->cut_handler( I<CODE_REF> )"
721 This is just like the code_handler attribute, except that it's for
722 "=cut" lines, not code lines. The same caveats apply. "=cut" lines
723 are unlikely to be interesting, but this is included for
724 completeness.
725 "$parser->whine( I<linenumber>, I<complaint string> )"
727 This notes a problem in the Pod, which will be reported to in the
728 "Pod Errors" section of the document and/or send to STDERR,
729 depending on the values of the attributes "no_whining",
730 "no_errata_section", and "complain_stderr".
731 "$parser->scream( I<linenumber>, I<complaint string> )"
733 This notes an error like "whine" does, except that it is not
734 suppressable with "no_whining". This should be used only for very
735 serious errors.
736 "$parser->source_dead(1)"
738 This aborts parsing of the current document, by switching on the
739 flag that indicates that EOF has been seen. In particularly
740 drastic cases, you might want to do this. It's rather nicer than
741 just calling "die"!
742 "$parser->hide_line_numbers( I<SOMEVALUE> )"
744 Some subclasses that indescriminately dump event attributes (well,
745 except for ones beginning with "~") can use this object attribute
746 for refraining to dump the "start_line" attribute.
747 "$parser->no_whining( I<SOMEVALUE> )"
749 This attribute, if set to true, will suppress reports of non-fatal
750 error messages. The default value is false, meaning that
751 complaints are reported. How they get reported depends on the
752 values of the attributes "no_errata_section" and "complain_stderr".
753 "$parser->no_errata_section( I<SOMEVALUE> )"
755 This attribute, if set to true, will suppress generation of an
756 errata section. The default value is false -- i.e., an errata
757 section will be generated.
758 "$parser->complain_stderr( I<SOMEVALUE> )"
760 This attribute, if set to true will send complaints to STDERR. The
761 default value is false -- i.e., complaints do not go to STDERR.
762 "$parser->bare_output( I<SOMEVALUE> )"
764 Some formatter subclasses use this as a flag for whether output
765 should have prologue and epilogue code omitted. For example,
766 setting this to true for an HTML formatter class should omit the
767 "<html><head><title>...</title><body>..." prologue and the
768 "</body></html>" epilogue.
769 If you want to set this to true, you should probably also set
771 "no_whining" or at least "no_errata_section" to true.
772 "$parser->preserve_whitespace( I<SOMEVALUE> )"
774 If you set this attribute to a true value, the parser will try to
775 preserve whitespace in the output. This means that such formatting
776 conventions as two spaces after periods will be preserved by the
777 parser. This is primarily useful for output formats that treat
778 whitespace as significant (such as text or *roff, but not HTML).
779
781 Pod::Simple -- event-based Pod-parsing framework
782 Pod::Simple::Methody -- like Pod::Simple, but each sort of event calls
784 its own method (like "start_head3")
785 Pod::Simple::PullParser -- a Pod-parsing framework like Pod::Simple,
787 but with a token-stream interface
788 Pod::Simple::SimpleTree -- a Pod-parsing framework like Pod::Simple,
790 but with a tree interface
791 Pod::Simple::Checker -- a simple Pod::Simple subclass that reads
793 documents, and then makes a plaintext report of any errors found in the
794 document
795 Pod::Simple::DumpAsXML -- for dumping Pod documents as tidily indented
797 XML, showing each event on its own line
798 Pod::Simple::XMLOutStream -- dumps a Pod document as XML (without
800 introducing extra whitespace as Pod::Simple::DumpAsXML does).
801 Pod::Simple::DumpAsText -- for dumping Pod documents as tidily indented
803 text, showing each event on its own line
804 Pod::Simple::LinkSection -- class for objects representing the values
806 of the TODO and TODO attributes of L<...> elements
807 Pod::Escapes -- the module the Pod::Simple uses for evaluating E<...>
809 content
810 Pod::Simple::Text -- a simple plaintext formatter for Pod
812 Pod::Simple::TextContent -- like Pod::Simple::Text, but makes no effort
814 for indent or wrap the text being formatted
815 perlpod
817 perlpodspec
819 perldoc
821
823 Questions or discussion about POD and Pod::Simple should be sent to the
824 pod-people@perl.org mail list. Send an empty email to
825 pod-people-subscribe@perl.org to subscribe.
826 This module is managed in an open GitHub repository,
828 <http://github.com/theory/pod-simple/>. Feel free to fork and
829 contribute, or to clone <git://github.com/theory/pod-simple.git> and
830 send patches!
831 Patches against Pod::Simple are welcome. Please send bug reports to
833 <bug-pod-simple@rt.cpan.org>.
834
836 Copyright (c) 2002 Sean M. Burke.
837 This library is free software; you can redistribute it and/or modify it
839 under the same terms as Perl itself.
840 This program is distributed in the hope that it will be useful, but
842 without any warranty; without even the implied warranty of
843 merchantability or fitness for a particular purpose.
844
846 Pod::Simple was created by Sean M. Burke <sburke@cpan.org>. But don't
847 bother him, he's retired.
848 Pod::Simple is maintained by:
850 · Allison Randal "allison@perl.org"
852 · Hans Dieter Pearcey "hdp@cpan.org"
854 · David E. Wheeler "dwheeler@cpan.org"
856perl v5.10.1 2017-03-22 Pod::Simple::Subclassing(3pm)