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
42 <http://lists.perl.org/showlist.cgi?name=pod-people> and asking whether
43 anyone has a formatter for that format -- maybe someone cobbled one
44 together but just hasn't released it.
45 The first step in writing a Pod processor is to read perlpodspec, which
47 contains notes information on writing a Pod parser (which has been
48 largely taken care of by Pod::Simple), but also a lot of requirements
49 and recommendations for writing a formatter.
50 The second step is to actually learn the format you're planning to
52 format to -- or at least as much as you need to know to represent Pod,
53 which probably isn't much.
54 The third step is to pick which of Pod::Simple's interfaces you want to
56 use -- the basic interface via Pod::Simple or Pod::Simple::Methody is
57 event-based, sort of like HTML::Parser's interface, or sort of like
58 XML::Parser's "Handlers" interface), but Pod::Simple::PullParser
59 provides a token-stream interface, sort of like HTML::TokeParser's
60 interface; Pod::Simple::SimpleTree provides a simple tree interface,
61 rather like XML::Parser's "Tree" interface. Users familiar with XML-
62 handling will find one of these styles relatively familiar; but if you
63 would be even more at home with XML, there are classes that produce an
64 XML representation of the Pod stream, notably
65 Pod::Simple::XMLOutStream; you can feed the output of such a class to
66 whatever XML parsing system you are most at home with.
67 The last step is to write your code based on how the events (or tokens,
69 or tree-nodes, or the XML, or however you're parsing) will map to
70 constructs in the output format. Also sure to consider how to escape
71 text nodes containing arbitrary text, and also what to do with text
72 nodes that represent preformatted text (from verbatim sections).
73
75 TODO intro... mention that events are supplied for implicits, like for
76 missing >'s
77 In the following section, we use XML to represent the event structure
79 associated with a particular construct. That is, TODO
80 "$parser->_handle_element_start( element_name, attr_hashref )"
82 "$parser->_handle_element_end( element_name )"
83 "$parser->_handle_text( text_string )"
84 TODO describe
86 events with an element_name of Document
88 Parsing a document produces this event structure:
89 <Document start_line="543">
91 ...all events...
92 </Document>
93 The value of the start_line attribute will be the line number of
95 the first Pod directive in the document.
96 If there is no Pod in the given document, then the event structure
98 will be this:
99 <Document contentless="1" start_line="543">
101 </Document>
102 In that case, the value of the start_line attribute will not be
104 meaningful; under current implementations, it will probably be the
105 line number of the last line in the file.
106 events with an element_name of Para
108 Parsing a plain (non-verbatim, non-directive, non-data) paragraph
109 in a Pod document produces this event structure:
110 <Para start_line="543">
112 ...all events in this paragraph...
113 </Para>
114 The value of the start_line attribute will be the line number of
116 the start of the paragraph.
117 For example, parsing this paragraph of Pod:
119 The value of the I<start_line> attribute will be the
121 line number of the start of the paragraph.
122 produces this event structure:
124 <Para start_line="129">
126 The value of the
127 <I>
128 start_line
129 </I>
130 attribute will be the line number of the first Pod directive
131 in the document.
132 </Para>
133 events with an element_name of B, C, F, or I.
135 Parsing a B<...> formatting code (or of course any of its
136 semantically identical syntactic variants B<< ... >>, or
137 B<<<< ... >>>>, etc.) produces this event structure:
138 <B>
140 ...stuff...
141 </B>
142 Currently, there are no attributes conveyed.
144 Parsing C, F, or I codes produce the same structure, with only a
146 different element name.
147 If your parser object has been set to accept other formatting
149 codes, then they will be presented like these B/C/F/I codes --
150 i.e., without any attributes.
151 events with an element_name of S
153 Normally, parsing an S<...> sequence produces this event structure,
154 just as if it were a B/C/F/I code:
155 <S>
157 ...stuff...
158 </S>
159 However, Pod::Simple (and presumably all derived parsers) offers
161 the "nbsp_for_S" option which, if enabled, will suppress all S
162 events, and instead change all spaces in the content to non-
163 breaking spaces. This is intended for formatters that output to a
164 format that has no code that means the same as S<...>, but which
165 has a code/character that means non-breaking space.
166 events with an element_name of X
168 Normally, parsing an X<...> sequence produces this event structure,
169 just as if it were a B/C/F/I code:
170 <X>
172 ...stuff...
173 </X>
174 However, Pod::Simple (and presumably all derived parsers) offers
176 the "nix_X_codes" option which, if enabled, will suppress all X
177 events and ignore their content. For formatters/processors that
178 don't use X events, this is presumably quite useful.
179 events with an element_name of L
181 Because the L<...> is the most complex construct in the language,
182 it should not surprise you that the events it generates are the
183 most complex in the language. Most of complexity is hidden away in
184 the attribute values, so for those of you writing a Pod formatter
185 that produces a non-hypertextual format, you can just ignore the
186 attributes and treat an L event structure like a formatting element
187 that (presumably) doesn't actually produce a change in formatting.
188 That is, the content of the L event structure (as opposed to its
189 attributes) is always what text should be displayed.
190 There are, at first glance, three kinds of L links: URL, man, and
192 pod.
193 When a L<some_url> code is parsed, it produces this event
195 structure:
196 <L content-implicit="yes" to="that_url" type="url">
198 that_url
199 </L>
200 The "type="url"" attribute is always specified for this type of L
202 code.
203 For example, this Pod source:
205 L<http://www.perl.com/CPAN/authors/>
207 produces this event structure:
209 <L content-implicit="yes" to="http://www.perl.com/CPAN/authors/" type="url">
211 http://www.perl.com/CPAN/authors/
212 </L>
213 When a L<manpage(section)> code is parsed (and these are fairly
215 rare and not terribly useful), it produces this event structure:
216 <L content-implicit="yes" to="manpage(section)" type="man">
218 manpage(section)
219 </L>
220 The "type="man"" attribute is always specified for this type of L
222 code.
223 For example, this Pod source:
225 L<crontab(5)>
227 produces this event structure:
229 <L content-implicit="yes" to="crontab(5)" type="man">
231 crontab(5)
232 </L>
233 In the rare cases where a man page link has a specified, that text
235 appears in a section attribute. For example, this Pod source:
236 L<crontab(5)/"ENVIRONMENT">
238 will produce this event structure:
240 <L content-implicit="yes" section="ENVIRONMENT" to="crontab(5)" type="man">
242 "ENVIRONMENT" in crontab(5)
243 </L>
244 In the rare case where the Pod document has code like
246 L<sometext|manpage(section)>, then the sometext will appear as the
247 content of the element, the manpage(section) text will appear only
248 as the value of the to attribute, and there will be no
249 "content-implicit="yes"" attribute (whose presence means that the
250 Pod parser had to infer what text should appear as the link text --
251 as opposed to cases where that attribute is absent, which means
252 that the Pod parser did not have to infer the link text, because
253 that L code explicitly specified some link text.)
254 For example, this Pod source:
256 L<hell itself!|crontab(5)>
258 will produce this event structure:
260 <L to="crontab(5)" type="man">
262 hell itself!
263 </L>
264 The last type of L structure is for links to/within Pod documents.
266 It is the most complex because it can have a to attribute, or a
267 section attribute, or both. The "type="pod"" attribute is always
268 specified for this type of L code.
269 In the most common case, the simple case of a L<podpage> code
271 produces this event structure:
272 <L content-implicit="yes" to="Net::Ping" type="pod">
274 podpage
275 </L>
276 For example, this Pod source:
278 L<Net::Ping>
280 produces this event structure:
282 <L content-implicit="yes" to="Net::Ping" type="pod">
284 Net::Ping
285 </L>
286 In cases where there is link-text explicitly specified, it is to be
288 found in the content of the element (and not the attributes), just
289 as with the L<sometext|manpage(section)> case discussed above. For
290 example, this Pod source:
291 L<Perl Error Messages|perldiag>
293 produces this event structure:
295 <L to="perldiag" type="pod">
297 Perl Error Messages
298 </L>
299 In cases of links to a section in the current Pod document, there
301 is a section attribute instead of a to attribute. For example,
302 this Pod source:
303 L</"Member Data">
305 produces this event structure:
307 <L content-implicit="yes" section="Member Data" type="pod">
309 "Member Data"
310 </L>
311 As another example, this Pod source:
313 L<the various attributes|/"Member Data">
315 produces this event structure:
317 <L section="Member Data" type="pod">
319 the various attributes
320 </L>
321 In cases of links to a section in a different Pod document, there
323 are both a section attribute and a to attribute. For example, this
324 Pod source:
325 L<perlsyn/"Basic BLOCKs and Switch Statements">
327 produces this event structure:
329 <L content-implicit="yes" section="Basic BLOCKs and Switch Statements" to="perlsyn" type="pod">
331 "Basic BLOCKs and Switch Statements" in perlsyn
332 </L>
333 As another example, this Pod source:
335 L<SWITCH statements|perlsyn/"Basic BLOCKs and Switch Statements">
337 produces this event structure:
339 <L section="Basic BLOCKs and Switch Statements" to="perlsyn" type="pod">
341 SWITCH statements
342 </L>
343 Incidentally, note that we do not distinguish between these
345 syntaxes:
346 L</"Member Data">
348 L<"Member Data">
349 L</Member Data>
350 L<Member Data> [deprecated syntax]
351 That is, they all produce the same event structure, namely:
353 <L content-implicit="yes" section="Member Data" type="pod">
355 "Member Data"
356 </L>
357 events with an element_name of E or Z
359 While there are Pod codes E<...> and Z<>, these do not produce any
360 E or Z events -- that is, there are no such events as E or Z.
361 events with an element_name of Verbatim
363 When a Pod verbatim paragraph (AKA "codeblock") is parsed, it
364 produces this event structure:
365 <Verbatim start_line="543" xml:space="preserve">
367 ...text...
368 </Verbatim>
369 The value of the start_line attribute will be the line number of
371 the first line of this verbatim block. The xml:space attribute is
372 always present, and always has the value "preserve".
373 The text content will have tabs already expanded.
375 events with an element_name of head1 .. head4
377 When a "=head1 ..." directive is parsed, it produces this event
378 structure:
379 <head1>
381 ...stuff...
382 </head1>
383 For example, a directive consisting of this:
385 =head1 Options to C<new> et al.
387 will produce this event structure:
389 <head1 start_line="543">
391 Options to
392 <C>
393 new
394 </C>
395 et al.
396 </head1>
397 "=head2" thru "=head4" directives are the same, except for the
399 element names in the event structure.
400 events with an element_name of over-bullet
402 When an "=over ... =back" block is parsed where the items are a
403 bulletted list, it will produce this event structure:
404 <over-bullet indent="4" start_line="543">
406 <item-bullet start_line="545">
407 ...Stuff...
408 </item-bullet>
409 ...more item-bullets...
410 </over-bullet>
411 The value of the indent attribute is whatever value is after the
413 "=over" directive, as in "=over 8". If no such value is specified
414 in the directive, then the indent attribute has the value "4".
415 For example, this Pod source:
417 =over
419 =item *
421 Stuff
423 =item *
425 Bar I<baz>!
427 =back
429 produces this event structure:
431 <over-bullet indent="4" start_line="10">
433 <item-bullet start_line="12">
434 Stuff
435 </item-bullet>
436 <item-bullet start_line="14">
437 Bar <I>baz</I>!
438 </item-bullet>
439 </over-bullet>
440 events with an element_name of over-number
442 When an "=over ... =back" block is parsed where the items are a
443 numbered list, it will produce this event structure:
444 <over-number indent="4" start_line="543">
446 <item-number number="1" start_line="545">
447 ...Stuff...
448 </item-number>
449 ...more item-number...
450 </over-bullet>
451 This is like the "over-bullet" event structure; but note that the
453 contents are "item-number" instead of "item-bullet", and note that
454 they will have a "number" attribute, which some
455 formatters/processors may ignore (since, for example, there's no
456 need for it in HTML when producing an "<UL><LI>...</LI>...</UL>"
457 structure), but which any processor may use.
458 Note that the values for the number attributes of "item-number"
460 elements in a given "over-number" area will start at 1 and go up by
461 one each time. If the Pod source doesn't follow that order (even
462 though it really should should!), whatever numbers it has will be
463 ignored (with the correct values being put in the number
464 attributes), and an error message might be issued to the user.
465 events with an element_name of over-text
467 These events are are somewhat unlike the other over-* structures,
468 as far as what their contents are. When an "=over ... =back" block
469 is parsed where the items are a list of text "subheadings", it will
470 produce this event structure:
471 <over-text indent="4" start_line="543">
473 <item-text>
474 ...stuff...
475 </item-text>
476 ...stuff (generally Para or Verbatim elements)...
477 <item-text>
478 ...more item-text and/or stuff...
479 </over-text>
480 The indent attribute is as with the other over-* events.
482 For example, this Pod source:
484 =over
486 =item Foo
488 Stuff
490 =item Bar I<baz>!
492 Quux
494 =back
496 produces this event structure:
498 <over-text indent="4" start_line="20">
500 <item-text start_line="22">
501 Foo
502 </item-text>
503 <Para start_line="24">
504 Stuff
505 </Para>
506 <item-text start_line="26">
507 Bar
508 <I>
509 baz
510 </I>
511 !
512 </item-text>
513 <Para start_line="28">
514 Quux
515 </Para>
516 </over-text>
517 events with an element_name of over-block
519 These events are are somewhat unlike the other over-* structures,
520 as far as what their contents are. When an "=over ... =back" block
521 is parsed where there are no items, it will produce this event
522 structure:
523 <over-block indent="4" start_line="543">
525 ...stuff (generally Para or Verbatim elements)...
526 </over-block>
527 The indent attribute is as with the other over-* events.
529 For example, this Pod source:
531 =over
533 For cutting off our trade with all parts of the world
535 For transporting us beyond seas to be tried for pretended offenses
537 He is at this time transporting large armies of foreign mercenaries to
539 complete the works of death, desolation and tyranny, already begun with
540 circumstances of cruelty and perfidy scarcely paralleled in the most
541 barbarous ages, and totally unworthy the head of a civilized nation.
542 =cut
544 will produce this event structure:
546 <over-block indent="4" start_line="2">
548 <Para start_line="4">
549 For cutting off our trade with all parts of the world
550 </Para>
551 <Para start_line="6">
552 For transporting us beyond seas to be tried for pretended offenses
553 </Para>
554 <Para start_line="8">
555 He is at this time transporting large armies of [...more text...]
556 </Para>
557 </over-block>
558 events with an element_name of item-bullet
560 See "events with an element_name of over-bullet", above.
561 events with an element_name of item-number
563 See "events with an element_name of over-number", above.
564 events with an element_name of item-text
566 See "events with an element_name of over-text", above.
567 events with an element_name of for
569 TODO...
570 events with an element_name of Data
572 TODO...
573
575 Pod::Simple provides a lot of methods that aren't generally interesting
576 to the end user of an existing Pod formatter, but some of which you
577 might find useful in writing a Pod formatter. They are listed below.
578 The first several methods (the accept_* methods) are for declaring the
579 capabilites of your parser, notably what "=for targetname" sections
580 it's interested in, what extra N<...> codes it accepts beyond the ones
581 described in the perlpod.
582 "$parser->accept_targets( SOMEVALUE )"
584 As the parser sees sections like:
585 =for html <img src="fig1.jpg">
587 or
589 =begin html
591 <img src="fig1.jpg">
593 =end html
595 ...the parser will ignore these sections unless your subclass has
597 specified that it wants to see sections targetted to "html" (or
598 whatever the formatter name is).
599 If you want to process all sections, even if they're not targetted
601 for you, call this before you start parsing:
602 $parser->accept_targets('*');
604 "$parser->accept_targets_as_text( SOMEVALUE )"
606 This is like accept_targets, except that it specifies also that the
607 content of sections for this target should be treated as Pod text
608 even if the target name in "=for targetname" doesn't start with a
609 ":".
610 At time of writing, I don't think you'll need to use this.
612 "$parser->accept_codes( Codename, Codename... )"
614 This tells the parser that you accept additional formatting codes,
615 beyond just the standard ones (I B C L F S X, plus the two weird
616 ones you don't actually see in the parse tree, Z and E). For
617 example, to also accept codes "N", "R", and "W":
618 $parser->accept_codes( qw( N R W ) );
620 TODO: document how this interacts with =extend, and long element
622 names
623 "$parser->accept_directive_as_data( directive_name )"
625 "$parser->accept_directive_as_verbatim( directive_name )"
626 "$parser->accept_directive_as_processed( directive_name )"
627 In the unlikely situation that you need to tell the parser that you
628 will accept additional directives ("=foo" things), you need to
629 first set the parset to treat its content as data (i.e., not really
630 processed at all), or as verbatim (mostly just expanding tabs), or
631 as processed text (parsing formatting codes like B<...>).
632 For example, to accept a new directive "=method", you'd presumably
634 use:
635 $parser->accept_directive_as_processed("method");
637 so that you could have Pod lines like:
639 =method I<$whatever> thing B<um>
641 Making up your own directives breaks compatibility with other Pod
643 formatters, in a way that using "=for target ..." lines doesn't;
644 however, you may find this useful if you're making a Pod superset
645 format where you don't need to worry about compatibility.
646 "$parser->nbsp_for_S( BOOLEAN );"
648 Setting this attribute to a true value (and by default it is false)
649 will turn "S<...>" sequences into sequences of words separated by
650 "\xA0" (non-breaking space) characters. For example, it will take
651 this:
652 I like S<Dutch apple pie>, don't you?
654 and treat it as if it were:
656 I like DutchE<nbsp>appleE<nbsp>pie, don't you?
658 This is handy for output formats that don't have anything quite
660 like an "S<...>" code, but which do have a code for non-breaking
661 space.
662 There is currently no method for going the other way; but I can
664 probably provide one upon request.
665 "$parser->version_report()"
667 This returns a string reporting the $VERSION value from your module
668 (and its classname) as well as the $VERSION value of Pod::Simple.
669 Note that perlpodspec requires output formats (wherever possible)
670 to note this detail in a comment in the output format. For
671 example, for some kind of SGML output format:
672 print OUT "<!-- \n", $parser->version_report, "\n -->";
674 "$parser->pod_para_count()"
676 This returns the count of Pod paragraphs seen so far.
677 "$parser->line_count()"
679 This is the current line number being parsed. But you might find
680 the "line_number" event attribute more accurate, when it is
681 present.
682 "$parser->nix_X_codes( SOMEVALUE )"
684 This attribute, when set to a true value (and it is false by
685 default) ignores any "X<...>" sequences in the document being
686 parsed. Many formats don't actually use the content of these
687 codes, so have no reason to process them.
688 "$parser->merge_text( SOMEVALUE )"
690 This attribute, when set to a true value (and it is false by
691 default) makes sure that only one event (or token, or node) will be
692 created for any single contiguous sequence of text. For example,
693 consider this somewhat contrived example:
694 I just LOVE Z<>hotE<32>apple pie!
696 When that is parsed and events are about to be called on it, it may
698 actually seem to be four different text events, one right after
699 another: one event for "I just LOVE ", one for "hot", one for " ",
700 and one for "apple pie!". But if you have merge_text on, then
701 you're guaranteed that it will be fired as one text event: "I just
702 LOVE hot apple pie!".
703 "$parser->code_handler( CODE_REF )"
705 This specifies code that should be called when a code line is seen
706 (i.e., a line outside of the Pod). Normally this is undef, meaning
707 that no code should be called. If you provide a routine, it should
708 start out like this:
709 sub get_code_line { # or whatever you'll call it
711 my($line, $line_number, $parser) = @_;
712 ...
713 }
714 Note, however, that sometimes the Pod events aren't processed in
716 exactly the same order as the code lines are -- i.e., if you have a
717 file with Pod, then code, then more Pod, sometimes the code will be
718 processed (via whatever you have code_handler call) before the all
719 of the preceding Pod has been processed.
720 "$parser->cut_handler( CODE_REF )"
722 This is just like the code_handler attribute, except that it's for
723 "=cut" lines, not code lines. The same caveats apply. "=cut" lines
724 are unlikely to be interesting, but this is included for
725 completeness.
726 "$parser->whine( linenumber, complaint string )"
728 This notes a problem in the Pod, which will be reported to in the
729 "Pod Errors" section of the document and/or send to STDERR,
730 depending on the values of the attributes "no_whining",
731 "no_errata_section", and "complain_stderr".
732 "$parser->scream( linenumber, complaint string )"
734 This notes an error like "whine" does, except that it is not
735 suppressable with "no_whining". This should be used only for very
736 serious errors.
737 "$parser->source_dead(1)"
739 This aborts parsing of the current document, by switching on the
740 flag that indicates that EOF has been seen. In particularly
741 drastic cases, you might want to do this. It's rather nicer than
742 just calling "die"!
743 "$parser->hide_line_numbers( SOMEVALUE )"
745 Some subclasses that indescriminately dump event attributes (well,
746 except for ones beginning with "~") can use this object attribute
747 for refraining to dump the "start_line" attribute.
748 "$parser->no_whining( SOMEVALUE )"
750 This attribute, if set to true, will suppress reports of non-fatal
751 error messages. The default value is false, meaning that
752 complaints are reported. How they get reported depends on the
753 values of the attributes "no_errata_section" and "complain_stderr".
754 "$parser->no_errata_section( SOMEVALUE )"
756 This attribute, if set to true, will suppress generation of an
757 errata section. The default value is false -- i.e., an errata
758 section will be generated.
759 "$parser->complain_stderr( SOMEVALUE )"
761 This attribute, if set to true will send complaints to STDERR. The
762 default value is false -- i.e., complaints do not go to STDERR.
763 "$parser->bare_output( SOMEVALUE )"
765 Some formatter subclasses use this as a flag for whether output
766 should have prologue and epilogue code omitted. For example,
767 setting this to true for an HTML formatter class should omit the
768 "<html><head><title>...</title><body>..." prologue and the
769 "</body></html>" epilogue.
770 If you want to set this to true, you should probably also set
772 "no_whining" or at least "no_errata_section" to true.
773 "$parser->preserve_whitespace( SOMEVALUE )"
775 If you set this attribute to a true value, the parser will try to
776 preserve whitespace in the output. This means that such formatting
777 conventions as two spaces after periods will be preserved by the
778 parser. This is primarily useful for output formats that treat
779 whitespace as significant (such as text or *roff, but not HTML).
780
782 Pod::Simple -- event-based Pod-parsing framework
783 Pod::Simple::Methody -- like Pod::Simple, but each sort of event calls
785 its own method (like "start_head3")
786 Pod::Simple::PullParser -- a Pod-parsing framework like Pod::Simple,
788 but with a token-stream interface
789 Pod::Simple::SimpleTree -- a Pod-parsing framework like Pod::Simple,
791 but with a tree interface
792 Pod::Simple::Checker -- a simple Pod::Simple subclass that reads
794 documents, and then makes a plaintext report of any errors found in the
795 document
796 Pod::Simple::DumpAsXML -- for dumping Pod documents as tidily indented
798 XML, showing each event on its own line
799 Pod::Simple::XMLOutStream -- dumps a Pod document as XML (without
801 introducing extra whitespace as Pod::Simple::DumpAsXML does).
802 Pod::Simple::DumpAsText -- for dumping Pod documents as tidily indented
804 text, showing each event on its own line
805 Pod::Simple::LinkSection -- class for objects representing the values
807 of the TODO and TODO attributes of L<...> elements
808 Pod::Escapes -- the module the Pod::Simple uses for evaluating E<...>
810 content
811 Pod::Simple::Text -- a simple plaintext formatter for Pod
813 Pod::Simple::TextContent -- like Pod::Simple::Text, but makes no effort
815 for indent or wrap the text being formatted
816 perlpod
818 perlpodspec
820 perldoc
822
824 Questions or discussion about POD and Pod::Simple should be sent to the
825 pod-people@perl.org mail list. Send an empty email to
826 pod-people-subscribe@perl.org to subscribe.
827 This module is managed in an open GitHub repository,
829 http://github.com/theory/pod-simple/ <http://github.com/theory/pod-
830 simple/>. Feel free to fork and contribute, or to clone
831 git://github.com/theory/pod-simple.git <git://github.com/theory/pod-
832 simple.git> and send patches!
833 Patches against Pod::Simple are welcome. Please send bug reports to
835 <bug-pod-simple@rt.cpan.org>.
836
838 Copyright (c) 2002 Sean M. Burke.
839 This library is free software; you can redistribute it and/or modify it
841 under the same terms as Perl itself.
842 This program is distributed in the hope that it will be useful, but
844 without any warranty; without even the implied warranty of
845 merchantability or fitness for a particular purpose.
846
848 Pod::Simple was created by Sean M. Burke <sburke@cpan.org>. But don't
849 bother him, he's retired.
850 Pod::Simple is maintained by:
852 · Allison Randal "allison@perl.org"
854 · Hans Dieter Pearcey "hdp@cpan.org"
856 · David E. Wheeler "dwheeler@cpan.org"
858perl v5.12.4 2011-06-07 Pod::Simple::Subclassing(3pm)