Do you have a question? Post it now! No Registration Necessary. Now with pictures!
July 8, 2006, 10:29 pm
rate this thread
The advantages are that the active maintainance of the two base classes
ensures my pod-to-pdf parser remains relatively free of bugs,
maintained by experts in the field (check-out their authors).
It also means slightly unweirldy code, in the manner of Pod::Checker.
Currently my pod-to-pdf module renders via PDF::API2* but unless I can
be bothered to get my head around that module's 'streaming' of data, Im
considering reaping the current Pod::Pdf, and merging it with my
current features, because my current understanding of the nature of
PDF::API2 is that it does not really support rendering either formatted
blocks of text nor serialised data. My code can make it perform as
reqired, but it was a pain in the neck to write, and will be a pain in
the foot to maintain. I think it is fair to say POD deserves a more
typographical system, and in my limited experience and vague memories
of University LaTEX seminars/assignments, I think something along those
lines is perhaps called for. I shall certainly give it a try, and post
Those current features are rather ephemera once the POD syntax checks
and PDF renderng have been done. I spent a fair amount of time writing
routines to corretly flow first a line then a pargraph then two columns
of text in PDF::API2 - no-one seems to have made anything fully
functional public, and with the experience behind me, I can almost see
The ephemeral features are:
* Automatic document table of contents. Easy but nice to have. It's an
option, and is not created unless requested.
* User-defined XML-based stylesheets to set formatting to each POD
element, from textblock, thourgh all the headings, to inline POD
sequences for italic, bold, and so on. Each style has settings for font
face, variation and style, as well as line and, when apt, block layout
* Implimentation of POD's X<...> index sequence to (optionally) create
an index that is appended to the POD PDF. This has been extended to
index the 'n' most infrequent words used, where 'n' is a number of the
users choice, and defaulting to about five for each page in the
As you can probably read, I was involoved in project documentation at
the time. It seemed very handy to produce an auto-indexed,
clearly-formatted document containing the POD for every module. As a
consequence, I may have missed something: please do point it out.
- » DBD::Unify on AIX : error -59 unable to attach to shared memory.
- — Next thread in » PERL Modules Announcements