Re: Which Pod module should be used / subclassed?

On 5/5/19 4:52 PM, Harald J=C3=B6rg wrote:
> Hello Pod-People,
>=20
> I hope that I don't start a religious war with this question.
> I found this mailing list advertised in the Pod::Simple docs, so I woul=
d
> accept a bias towards Pod::Simple based solutions :)
>=20
> So here's what I want to do: Extract Pod from a bunch of (ca 100) Perl
> modules and Pod files and convert it to HTML.  Or XHTML.  Anything good
> for today's browsers is fine.  Sounds pretty TIMTOWTDI, but every way
> I've tried so far has minor issues, and I've some requirements for whic=
h
> I haven't found an existing solution yet.
>=20
> The issues are rather harmless:
>=20
>   - Pod::POM is what's used today in the software to create the HTML
>     docs.  It fails to process L<The Perl Homepage|https://www.perl.org=
>
>     links correctly.
>=20
>   - Pod::Simple::HTML produces invalid HTML (nested 'a' elements) when =
a
>     heading or item contains a Link like this:
>=20
>       =3Dhead1 Start at L<https://www.perl.org>
>=20
>   - Pod::Simple::XHTML apparently makes no effort to find content for t=
he
>     <title> element (nor does core pod2html, BTW).
>=20
> And there are a few things I miss.  They could be implemented in a
> subclass of either of these, or even provided as an enhancement via Pul=
l
> Request:
>=20
>   - A custom link resolver: I want links to documents within the projec=
t
>     to be relative, but link to other CPAN modules to be
>     absolute. Preferably to metacpan.org instead of search.cpan.org.
>=20
>   - A custom table of contents
>=20
>   - Custom (or just different) backlinks to top of page
>=20
>   - Decent heuristics for page titles (Pod::Simple::PullParser does tha=
t
>     marvelously)
>=20
>   - ...and some more, but not enough to roll out my own converter.
>=20
> So, which if the modules is considered "state of the art" by the Pod
> People?  Which one of them is least likely to be deprecated?
>=20
> Do others have similar requirements?
>=20

I seem to be the one mostly maintaining Pod:Simple these days.  I think=20
the design of Pod::Simple is basically sound.  If you came up with=20
reasonable pull requests for either of those modules, I would apply them.

All those TODOs in the code are from the original author, I believe, and=20
they would be nice to have, but the code basically works and no one has=20
felt the need to spend the effort to implement them.