Of course, sublassing the module would be a better option. :-)

Update: The other problem, that I mention above, was the way that function descriptions in =head* are treated differently depending on the number of parameters that they have. For example here is some simple pod and the output from pod2html:

    =head1 NAME

    Test - Some pod

    =head2 function1()

    Some text here.

    =head2 function2($foo)

    Some text "here".

    =head2 function3($foo, $bar)

    Some text here.

    =head2 function4($foo,$bar)

    Some text here.

    =cut
[download]

NAME

Test - Some pod

function1()

Some text here.

function2($foo)

Some text ``here''.

function3($foo, $bar)

Some text here.

function4($foo,$bar)

Some text here.

For some, possibly valid reason the third function isn't given code tags. This wasn't what I wanted however, so I modified the Pod::Html code to get the same behaviour in each of the above cases.

--
John.

I see, the code is not extensible at all, or even fully modular.

Interesting about the function with 2 arguments! How strange.

—John

Neither will Pod::POM, or Pod::Simple, or even Pod::Tree (beware though, it overwrites pod2html, but is similar to pod2html, and provides utilities like mpod2html to generate a toc/index, but is they don't work too well).

BTW - it's Pod::Html last I checked ;)(although it may actually be HTML.pm in some ActivePerl distros)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy.

The one I was using generates a table of contents. How is mpod2html different regarding that?

I'll beware of Pod::Tree, thanks.

—John