Pod::Simple::Subclassing -- 将格式化程序编写为 Pod::Simple 子类
package Pod::SomeFormatter;
use Pod::Simple;
@ISA = qw(Pod::Simple);
$VERSION = '1.01';
use strict;
sub _handle_element_start {
my($parser, $element_name, $attr_hash_r) = @_;
...
}
sub _handle_element_end {
my($parser, $element_name, $attr_hash_r) = @_;
# NOTE: $attr_hash_r is only present when $element_name is "over" or "begin"
# The remaining code excerpts will mostly ignore this $attr_hash_r, as it is
# mostly useless. It is documented where "over-*" and "begin" events are
# documented.
...
}
sub _handle_text {
my($parser, $text) = @_;
...
}
1;本文档介绍如何使用 Pod::Simple 编写 Pod 处理器，通常是 Pod 格式化程序。如果您只想了解如何使用现有的 Pod 格式化程序，请参阅其文档，并参阅 Pod::Simple 中的文档。
第一步 在编写 Pod 格式化程序时，要确保 CPAN 中还没有合适的格式化程序。请访问 http://search.cpan.org/，并搜索您要渲染的格式的名称。还可以考虑加入 Pod People 列表 http://lists.perl.org/showlist.cgi?name=pod-people 并询问是否有人拥有该格式的格式化程序 - 也许有人拼凑了一个格式化程序，但还没有发布。
第二步 在编写 Pod 处理器时，要阅读 perlpodspec，其中包含有关编写 Pod 解析器（Pod::Simple 已在很大程度上处理了）的信息，但也包含许多编写格式化程序的要求和建议。
第三步 是实际学习您计划格式化的格式 - 或者至少了解您需要了解的有关表示 Pod 的知识，这可能并不多。
第四步 是选择要使用 Pod::Simple 的哪个接口
使用_handle_element_start()、_handle_element_end() 和 _handle_text() 的基本 Pod::Simple 接口。
Pod::Simple::Methody 接口是基于事件的，类似于 HTML::Parser 或 XML::Parser 的“Handlers”。
Pod::Simple::PullParser 提供了一个类似于 HTML::TokeParser 接口的标记流接口。
Pod::Simple::SimpleTree 提供了一个简单的树接口，类似于 XML::Parser 的“Tree”接口。熟悉 XML 处理的用户会对这个接口感到熟悉。有兴趣输出 XML 的用户应该查看生成 Pod 流 XML 表示的模块，特别是 Pod::Simple::XMLOutStream；您可以将此类类的输出馈送到您最熟悉的任何 XML 解析系统。
最后一步是根据事件（或标记、或树节点、或 XML，或您解析的方式）如何映射到输出格式中的构造来编写代码。还要确保考虑如何转义包含任意文本的文本节点，以及如何处理表示预格式化文本（来自逐字节段）的文本节点。
TODO 简介... 提到为隐式提供事件，例如缺少 >'s
在以下部分，我们使用 XML 来表示与特定构造相关的事件结构。也就是说，一个开始标签表示元素开始，该开始标签的属性是传递给回调的属性，结束标签表示结束元素。
扩展 Pod::Simple 的类必须提供三个回调方法来接收相应的事件
$parser->_handle_element_start( element_name, attr_hashref )$parser->_handle_element_end( element_name )$parser->_handle_text( text_string )以下是您在 _handle_element_start 和 _handle_element_end 的实现中可以期望作为 element_name 的值列表：
解析文档会生成以下事件结构
<Document start_line="543">
...all events...
</Document>start_line 属性的值将是文档中第一个 Pod 指令的行号。
如果给定文档中没有 Pod，则事件结构将是以下
<Document contentless="1" start_line="543">
</Document>在这种情况下，start_line 属性的值将没有意义；在当前实现中，它可能是在文件中的最后一行。
解析 Pod 文档中的普通（非文字、非指令、非数据）段落会生成以下事件结构
<Para start_line="543">
...all events in this paragraph...
</Para>start_line 属性的值将是段落开始的行号。
例如，解析以下 Pod 段落
The value of the I<start_line> attribute will be the
line number of the start of the paragraph.会生成以下事件结构
<Para start_line="129">
The value of the
<I>
start_line
</I>
attribute will be the line number of the first Pod directive
in the document.
</Para>解析 B<...> 格式化代码（或者当然任何语义上相同的语法变体 B<< ... >>，或 B<<<< ... >>>> 等）会生成以下事件结构
<B>
...stuff...
</B>目前，没有传递任何属性。
解析 C、F 或 I 代码会生成相同的结构，只是元素名称不同。
如果您的解析器对象已设置为接受其他格式化代码，那么它们将像这些 B/C/F/I 代码一样呈现——即，没有任何属性。
通常，解析 S<...> 序列会生成以下事件结构，就像它是 B/C/F/I 代码一样
<S>
...stuff...
</S>但是，Pod::Simple（以及可能所有派生解析器）提供了 nbsp_for_S 选项，如果启用，它将抑制所有 S 事件，并将内容中的所有空格更改为不间断空格。这是为那些输出到没有与 S<...> 相同含义的代码的格式，但有表示不间断空格的代码/字符的格式而设计的。
通常，解析 X<...> 序列会生成以下事件结构，就像它是 B/C/F/I 代码一样
<X>
...stuff...
</X>然而，Pod::Simple（以及所有推测的派生解析器）提供了nix_X_codes选项，如果启用，将抑制所有 X 事件并忽略其内容。对于不使用 X 事件的格式化程序/处理器，这可能非常有用。
由于 L<...> 是该语言中最复杂的结构，因此您不应该对它生成的事件是该语言中最复杂的事件感到惊讶。大多数复杂性隐藏在属性值中，因此对于那些编写生成非超文本格式的 Pod 格式化程序的人来说，您可以忽略属性并将 L 事件结构视为一个格式化元素（可能）实际上不会产生格式更改。也就是说，L 事件结构的内容（与其属性相反）始终是应该显示的文本。
乍一看，有三种类型的 L 链接：URL、man 和 pod。
当解析 L<some_url> 代码时，它会生成以下事件结构
<L content-implicit="yes" raw="that_url" to="that_url" type="url">
that_url
</L>type="url" 属性始终为此类型的 L 代码指定。
例如，此 Pod 源代码
L<https://perldotcom.perl5.cn/CPAN/authors/>会生成以下事件结构
<L content-implicit="yes" raw="https://perldotcom.perl5.cn/CPAN/authors/" to="https://perldotcom.perl5.cn/CPAN/authors/" type="url">
https://perldotcom.perl5.cn/CPAN/authors/
</L>当解析 L<manpage(section)> 代码时（这些代码相当罕见且不太有用），它会生成以下事件结构
<L content-implicit="yes" raw="manpage(section)" to="manpage(section)" type="man">
manpage(section)
</L>type="man" 属性始终为此类型的 L 代码指定。
例如，此 Pod 源代码
L<crontab(5)>会生成以下事件结构
<L content-implicit="yes" raw="crontab(5)" to="crontab(5)" type="man">
crontab(5)
</L>在很少的情况下，手册页链接指定了部分，该文本将出现在section属性中。例如，此 Pod 源代码
L<crontab(5)/"ENVIRONMENT">将生成以下事件结构
<L content-implicit="yes" raw="crontab(5)/"ENVIRONMENT"" section="ENVIRONMENT" to="crontab(5)" type="man">
"ENVIRONMENT" in crontab(5)
</L>在 Pod 文档包含类似 L<sometext|manpage(section)> 的代码的罕见情况下，sometext 将显示为元素的内容，manpage(section) 文本将仅显示为to属性的值，并且不会有content-implicit="yes"属性（其存在意味着 Pod 解析器必须推断应该显示为链接文本的文本 - 与该属性不存在的情况相反，这意味着 Pod 解析器没有推断链接文本，因为该 L 代码明确指定了一些链接文本。）
例如，此 Pod 源代码
L<hell itself!|crontab(5)>将生成以下事件结构
<L raw="hell itself!|crontab(5)" to="crontab(5)" type="man">
hell itself!
</L>最后一种类型的 L 结构用于链接到 Pod 文档或 Pod 文档内的链接。它是最复杂的，因为它可以具有to属性，或section属性，或两者兼而有之。type="pod" 属性始终为此类型的 L 代码指定。
在最常见的情况下，L<podpage> 代码的简单情况会生成以下事件结构
<L content-implicit="yes" raw="podpage" to="podpage" type="pod">
podpage
</L>例如，此 Pod 源代码
L<Net::Ping>会生成以下事件结构
<L content-implicit="yes" raw="Net::Ping" to="Net::Ping" type="pod">
Net::Ping
</L>在明确指定链接文本的情况下，它将出现在元素的内容中（而不是属性中），就像上面讨论的 L<sometext|manpage(section)> 案例一样。例如，此 Pod 源代码
L<Perl Error Messages|perldiag>会生成以下事件结构
<L raw="Perl Error Messages|perldiag" to="perldiag" type="pod">
Perl Error Messages
</L>在链接到当前 Pod 文档中的部分的情况下，有一个section属性而不是to属性。例如，此 Pod 源代码
L</"Member Data">会生成以下事件结构
<L content-implicit="yes" raw="/"Member Data"" section="Member Data" type="pod">
"Member Data"
</L>举个例子，这个 Pod 源代码
L<the various attributes|/"Member Data">会生成以下事件结构
<L raw="the various attributes|/"Member Data"" section="Member Data" type="pod">
the various attributes
</L>如果链接到另一个 Pod 文档中的某个部分，则会同时存在一个 section 属性和一个 to 属性。例如，这个 Pod 源代码
L<perlsyn/"Basic BLOCKs and Switch Statements">会生成以下事件结构
<L content-implicit="yes" raw="perlsyn/"Basic BLOCKs and Switch Statements"" section="Basic BLOCKs and Switch Statements" to="perlsyn" type="pod">
"Basic BLOCKs and Switch Statements" in perlsyn
</L>举个例子，这个 Pod 源代码
L<SWITCH statements|perlsyn/"Basic BLOCKs and Switch Statements">会生成以下事件结构
<L raw="SWITCH statements|perlsyn/"Basic BLOCKs and Switch Statements"" section="Basic BLOCKs and Switch Statements" to="perlsyn" type="pod">
SWITCH statements
</L>顺便说一下，请注意我们不区分这些语法
L</"Member Data">
L<"Member Data">
L</Member Data>
L<Member Data> [deprecated syntax]也就是说，它们都生成相同的事件结构（在大多数情况下），即
<L content-implicit="yes" raw="$depends_on_syntax" section="Member Data" type="pod">
"Member Data"
</L>raw 属性取决于 L<> 的原始内容，因此事件结构在“大多数情况下”是相同的。
如果你还没有猜到，raw 属性包含 L<> 格式化代码的原始、原始、未转义的内容。除了上面的例子，请注意以下 L<> 格式化代码生成的事件结构。
L<click B<here>|page/About the C<-M> switch>
<L raw="click B<here>|page/About the C<-M> switch" section="About the -M switch" to="page" type="pod">
click B<here>
</L>具体来说，请注意格式化代码在 raw 中存在且未转义。
raw 属性中存在一个已知的错误，即任何周围的空格都会压缩成一个单一的 ' '。例如，给定 L< link>，raw 将为 " link"。
虽然存在 Pod 代码 E<...> 和 Z<>，但它们不会生成任何 E 或 Z 事件 - 也就是说，不存在 E 或 Z 这样的事件。
当解析 Pod 逐字段落（又称“代码块”）时，它会生成此事件结构
<Verbatim start_line="543" xml:space="preserve">
...text...
</Verbatim>start_line 属性的值将是此逐字块的第一行的行号。xml:space 属性始终存在，并且始终具有值 "preserve"。
文本内容将已经扩展了制表符。
当解析 "=head1 ..." 指令时，它会生成此事件结构
<head1>
...stuff...
</head1>例如，一个包含以下内容的指令
=head1 Options to C<new> et al.将生成以下事件结构
<head1 start_line="543">
Options to
<C>
new
</C>
et al.
</head1>"=head2" 到 "=head4" 指令相同，只是事件结构中的元素名称不同。
在默认情况下，不会发出与 =encoding 指令相对应的事件。如果 keep_encoding_directive 为 true，则会发出它们。在这种情况下，它们会生成类似于 "元素名称为 head1 .. head4 的事件" 的事件结构。
当解析 "=over ... =back" 块时，如果项目是项目符号列表，它将生成此事件结构
<over-bullet indent="4" start_line="543">
<item-bullet start_line="545">
...Stuff...
</item-bullet>
...more item-bullets...
</over-bullet fake-closer="1">fake-closer 属性仅在值为真时存在；如果值为假，则不存在。在上面的示例中显示它是为了说明属性的位置（在closing标签中）。它表示=over没有匹配的=back，因此 Pod::Simple 必须创建一个假的结束符。
例如，此 Pod 源代码
=over
=item *
Something
=back将生成一个没有fake-closer 属性的事件结构，而此 Pod 源代码
=over
=item *
Gasp! An unclosed =over block!则会生成。其余的 over-* 示例不会演示此属性，但它们都可能具有此属性。有关此属性使用示例，请参阅Pod::Checker的源代码。
indent 属性的值是在 "=over" 指令后的任何值，例如 "=over 8"。如果指令中未指定此类值，则indent 属性的值为 "4"。
例如，此 Pod 源代码
=over
=item *
Stuff
=item *
Bar I<baz>!
=back会生成以下事件结构
<over-bullet indent="4" start_line="10">
<item-bullet start_line="12">
Stuff
</item-bullet>
<item-bullet start_line="14">
Bar <I>baz</I>!
</item-bullet>
</over-bullet>当解析 "=over ... =back" 块，其中项目是编号列表时，它将生成此事件结构
<over-number indent="4" start_line="543">
<item-number number="1" start_line="545">
...Stuff...
</item-number>
...more item-number...
</over-bullet>这类似于 "over-bullet" 事件结构；但请注意，内容是 "item-number" 而不是 "item-bullet"，并且请注意它们将具有 "number" 属性，某些格式化程序/处理器可能会忽略此属性（例如，在生成 "<UL><LI>...</LI>...</UL>" 结构时，HTML 中不需要此属性），但任何处理器都可以使用此属性。
请注意，给定 "over-number" 区域中 "item-number" 元素的number 属性的值将从 1 开始，每次增加 1。如果 Pod 源代码不遵循此顺序（即使它确实应该！），它所具有的任何数字都将被忽略（使用正确的数字放入number 属性中），并且可能会向用户发出错误消息。
这些事件在内容方面与其他 over-* 结构有所不同。当解析一个 "=over ... =back" 块，其中项目是文本 "子标题" 列表时，它将生成此事件结构
<over-text indent="4" start_line="543">
<item-text>
...stuff...
</item-text>
...stuff (generally Para or Verbatim elements)...
<item-text>
...more item-text and/or stuff...
</over-text>indent 和 fake-closer 属性与其他 over-* 事件相同。
例如，此 Pod 源代码
=over
=item Foo
Stuff
=item Bar I<baz>!
Quux
=back会生成以下事件结构
<over-text indent="4" start_line="20">
<item-text start_line="22">
Foo
</item-text>
<Para start_line="24">
Stuff
</Para>
<item-text start_line="26">
Bar
<I>
baz
</I>
!
</item-text>
<Para start_line="28">
Quux
</Para>
</over-text>这些事件在内容方面与其他 over-* 结构有所不同。当解析一个 "=over ... =back" 块，其中没有项目时，它将生成此事件结构
<over-block indent="4" start_line="543">
...stuff (generally Para or Verbatim elements)...
</over-block>indent 和 fake-closer 属性与其他 over-* 事件相同。
例如，此 Pod 源代码
=over
For cutting off our trade with all parts of the world
For transporting us beyond seas to be tried for pretended offenses
He is at this time transporting large armies of foreign mercenaries to
complete the works of death, desolation and tyranny, already begun with
circumstances of cruelty and perfidy scarcely paralleled in the most
barbarous ages, and totally unworthy the head of a civilized nation.
=back将生成以下事件结构
<over-block indent="4" start_line="2">
<Para start_line="4">
For cutting off our trade with all parts of the world
</Para>
<Para start_line="6">
For transporting us beyond seas to be tried for pretended offenses
</Para>
<Para start_line="8">
He is at this time transporting large armies of [...more text...]
</Para>
</over-block>注意：只有当 parse_empty_lists() 设置为真值时，才会触发这些事件。
这些事件在内容方面与其他 over-* 结构有所不同。当解析一个 "=over ... =back" 块，其中没有内容时，它将生成此事件结构
<over-empty indent="4" start_line="543">
</over-empty>indent 和 fake-closer 属性与其他 over-* 事件相同。
例如，此 Pod 源代码
=over
=over
=back
=back将生成以下事件结构
<over-block indent="4" start_line="1">
<over-empty indent="4" start_line="3">
</over-empty>
</over-block>请注意，外部 =over 是一个块，因为它没有 =item，但仍然有内容：内部 =over。内部 =over 反过来是完全空的，并被视为这样。
参见上面的 "元素名为 over-bullet 的事件"。
参见上面的 "元素名为 over-number 的事件"。
参见上面的 "元素名为 over-text 的事件"。
待办事项...
待办事项...
Pod::Simple 提供了许多方法，这些方法对于现有 Pod 格式化程序的最终用户来说通常并不有趣，但您可能会发现它们在编写 Pod 格式化程序时很有用。它们列在下面。前几个方法（accept_* 方法）用于声明解析器的功能，特别是它感兴趣的=for targetname 部分，以及它除了perlpod 中描述的那些之外接受的额外 N<...> 代码。
$parser->accept_targets( SOMEVALUE )当解析器看到类似于
=for html <img src="fig1.jpg">或
=begin html
<img src="fig1.jpg">
=end html...的节时，解析器将忽略这些节，除非您的子类指定它希望看到针对“html”（或格式化程序名称）的节。
如果您想处理所有节，即使它们不是针对您的，在开始解析之前调用此方法
$parser->accept_targets('*');$parser->accept_targets_as_text( SOMEVALUE )这类似于 accept_targets，只是它还指定了针对此目标的节的内容应被视为 Pod 文本，即使"=for targetname" 中的目标名称不以“:”开头。
在撰写本文时，我认为您不需要使用它。
$parser->accept_codes( Codename, Codename... )这告诉解析器您接受额外的格式化代码，而不仅仅是标准代码（I B C L F S X，加上您实际上在解析树中看不到的两个奇怪代码，Z 和 E）。例如，要接受代码“N”、“R”和“W”
$parser->accept_codes( qw( N R W ) );TODO：记录这如何与 =extend 和长元素名称交互
$parser->accept_directive_as_data( directive_name )$parser->accept_directive_as_verbatim( directive_name )$parser->accept_directive_as_processed( directive_name )在极少数情况下，您需要告诉解析器您将接受额外的指令（“=foo”内容），您需要首先将解析器设置为将其内容视为数据（即，根本不进行处理），或视为逐字文本（主要只是扩展制表符），或视为已处理文本（解析格式代码，如 B<...>）。
例如，要接受新的指令“=method”，您可能需要使用
$parser->accept_directive_as_processed("method");这样您就可以使用像这样的 Pod 行
=method I<$whatever> thing B<um>创建您自己的指令会破坏与其他 Pod 格式化程序的兼容性，而使用“=for target …”行则不会；但是，如果您正在创建 Pod 超集格式，并且不需要担心兼容性，那么您可能会发现这很有用。
$parser->nbsp_for_S( BOOLEAN );将此属性设置为真值（默认情况下为假）将把“S<...>”序列转换为由\xA0（不间断空格）字符分隔的单词序列。例如，它将接受以下内容
I like S<Dutch apple pie>, don't you?并将其视为
I like DutchE<nbsp>appleE<nbsp>pie, don't you?这对于没有完全类似“S<...>”代码但有非换行空格代码的输出格式非常有用。
目前还没有反向操作的方法；但我可能可以根据要求提供一个。
$parser->version_report()这将返回一个字符串，报告您模块（及其类名）的 $VERSION 值以及 Pod::Simple 的 $VERSION 值。请注意，perlpodspec 要求输出格式（在可能的情况下）在输出格式的注释中注明此细节。例如，对于某种 SGML 输出格式
print OUT "<!-- \n", $parser->version_report, "\n -->";$parser->pod_para_count()这将返回迄今为止看到的 Pod 段落的数量。
$parser->line_count()这是正在解析的当前行号。但是，当存在时，您可能会发现“line_number”事件属性更准确。
$parser->nix_X_codes( SOMEVALUE )此属性在设置为真值时（默认情况下为假）会忽略正在解析的文档中的任何“X<...>”序列。许多格式实际上不使用这些代码的内容，因此没有理由处理它们。
$parser->keep_encoding_directive( SOMEVALUE )当此属性设置为真值（默认值为假）时，它将在事件结构中保留=encoding及其内容。大多数格式实际上不需要处理=encoding指令的内容，即使此指令设置了编码并且处理器使用了编码信息。实际上，即使不处理指令内容，也可以知道编码。
$parser->merge_text( SOMEVALUE )当此属性设置为真值（默认值为假）时，它将确保仅为任何单个连续文本序列创建一个事件（或标记或节点）。例如，考虑这个有点人为的例子
I just LOVE Z<>hotE<32>apple pie!当解析它并即将对其调用事件时，它实际上似乎是四个不同的文本事件，一个接一个：一个事件用于“I just LOVE”，一个用于“hot”，一个用于“”，一个用于“apple pie!”。但是，如果您打开了merge_text，那么您将保证它将被触发为一个文本事件：“I just LOVE hot apple pie!”。
$parser->code_handler( CODE_REF )这指定了在看到代码行时应该调用的代码（即 Pod 之外的行）。通常这是 undef，这意味着不应该调用任何代码。如果您提供了一个例程，它应该像这样开始
sub get_code_line { # or whatever you'll call it
my($line, $line_number, $parser) = @_;
...
}但是，请注意，有时 Pod 事件的处理顺序与代码行的处理顺序并不完全相同——即，如果您有一个包含 Pod、然后是代码、然后是更多 Pod 的文件，有时代码将在所有前面的 Pod 都被处理之前被处理（通过您设置的 code_handler 调用）。
$parser->cut_handler( CODE_REF )这与 code_handler 属性类似，只是它用于“=cut”行，而不是代码行。相同的注意事项适用。“=cut”行不太可能令人感兴趣，但为了完整性而包含在内。
$parser->pod_handler( CODE_REF )这与 code_handler 属性类似，只是它用于“=pod”行，而不是代码行。相同的注意事项适用。“=pod”行不太可能令人感兴趣，但为了完整性而包含在内。
$parser->whiteline_handler( CODE_REF )这与 code_handler 属性类似，不同之处在于它用于看似空白但包含空格（“ ” 和/或 “\t”）的行，而不是代码行。相同的注意事项适用。这些行不太可能有趣，但为了完整性而包含在内。
$parser->whine( linenumber, complaint string )这会记录 Pod 中的问题，该问题将在文档的“Pod 错误”部分报告，或发送到 STDERR，具体取决于属性 no_whining、no_errata_section 和 complain_stderr 的值。
$parser->scream( linenumber, complaint string )这会记录类似于 whine 的错误，不同之处在于它不能通过 no_whining 抑制。这应该仅用于非常严重的错误。
$parser->source_dead(1)这会通过打开指示已看到 EOF 的标志来中止当前文档的解析。在特别严重的情况下，您可能希望这样做。这比直接调用 die 好多了！
$parser->hide_line_numbers( SOMEVALUE )一些不加区别地转储事件属性（除了以“~”开头的属性）的子类可以使用此对象属性来避免转储“start_line”属性。
$parser->no_whining( SOMEVALUE )如果将此属性设置为 true，则会抑制非致命错误消息的报告。默认值为 false，这意味着会报告投诉。它们如何被报告取决于属性 no_errata_section 和 complain_stderr 的值。
$parser->no_errata_section( SOMEVALUE )如果将此属性设置为 true，则会抑制错误信息部分的生成。默认值为 false，即会生成错误信息部分。
$parser->complain_stderr( SOMEVALUE )如果将此属性设置为 true，则会将投诉发送到 STDERR。默认值为 false，即投诉不会发送到 STDERR。
$parser->bare_output( SOMEVALUE )一些格式化程序子类使用此作为标志，用于指示输出是否应省略序言和结语代码。例如，对于 HTML 格式化程序类，将此设置为 true 应该会省略 "<html><head><title>...</title><body>..." 序言和 "</body></html>" 结语。
如果要将此设置为 true，则可能还需要将 no_whining 或至少 no_errata_section 设置为 true。
$parser->preserve_whitespace( SOMEVALUE )如果将此属性设置为 true 值，则解析器将尝试在输出中保留空格。这意味着解析器将保留诸如句点后两个空格之类的格式约定。这主要适用于将空格视为重要（如文本或 *roff，但不包括 HTML）的输出格式。
$parser->parse_empty_lists( SOMEVALUE )如果将此属性设置为 true，则解析器将不会忽略空的 =over/=back 块。=over 的类型将为 empty，如上所述，"element_name 为 over-empty 的事件"。
Pod::Simple -- 基于事件的 Pod 解析框架
Pod::Simple::Methody -- 与 Pod::Simple 相似，但每种事件类型都会调用其自己的方法（如 start_head3）
Pod::Simple::PullParser -- 与 Pod::Simple 相似的 Pod 解析框架，但具有令牌流接口
Pod::Simple::SimpleTree -- 与 Pod::Simple 相似的 Pod 解析框架，但具有树接口
Pod::Simple::Checker -- 一个简单的 Pod::Simple 子类，它读取文档，然后生成一个纯文本报告，其中包含在文档中发现的任何错误
Pod::Simple::DumpAsXML -- 用于将 Pod 文档以整齐缩进的 XML 格式转储，将每个事件显示在单独的行上
Pod::Simple::XMLOutStream -- 将 Pod 文档转储为 XML（不会像 Pod::Simple::DumpAsXML 那样引入额外的空格）。
Pod::Simple::DumpAsText -- 用于将 Pod 文档转储为整齐缩进的文本，在单独的行上显示每个事件
Pod::Simple::LinkSection -- 表示 L<...> 元素的 TODO 和 TODO 属性值的类的对象
Pod::Escapes -- Pod::Simple 用于评估 E<...> 内容的模块
Pod::Simple::Text -- Pod 的简单纯文本格式化程序
Pod::Simple::TextContent -- 与 Pod::Simple::Text 相似，但不会尝试缩进或换行要格式化的文本
Pod::Simple::HTML -- Pod 的简单 HTML 格式化程序
有关 POD 和 Pod::Simple 的问题或讨论应发送到 [email protected] 邮件列表。发送空邮件到 [email protected] 订阅。
此模块在开放的 GitHub 存储库中管理，https://github.com/perl-pod/pod-simple/。欢迎您随意分叉和贡献，或克隆 git://github.com/perl-pod/pod-simple.git 并发送补丁！
欢迎针对 Pod::Simple 的补丁。请将错误报告发送到 <[email protected]>。
版权所有 (c) 2002 Sean M. Burke。
此库是免费软件；您可以根据与 Perl 本身相同的条款重新分发和/或修改它。
此程序按“原样”提供，不提供任何形式的明示或暗示保证，包括但不限于适销性保证和特定用途适用性的保证。
Pod::Simple 由 Sean M. Burke <[email protected]> 创建。但不要打扰他，他已经退休了。
Pod::Simple 由以下人员维护：
Allison Randal [email protected]
Hans Dieter Pearcey [email protected]
David E. Wheeler [email protected]