Front page | perl.perl5.porters |
Postings from December 2021
In helping with a little POD update recently, I was introduced to Swim, https://metacpan.org/pod/Swim Seems to cover most of the cases discussed here as part of a toolchain. It also supports includes (e.g., header, footer). E.g., https://github.com/ingydotnet/inline-c-pm/blob/master/doc/Inline/C/Cookbook.swim The table thing is a different problem to solve, but it seems like that will turn out to use verbatim sections with the ability to align tables as part of an intermediate tool, perhaps? For images, it has a free form HTML capability, I am not suggesting this as _the_ solution, but if there was indeed a formalization of the toolchain flow this might provide a workable option. Cheers, Brett * William Lindley <wlindley@wlindley.com> [2021-11-30 08:57:58 -0500]: > On 11/29/21 11:14 PM, Oodler 577 via perl5-porters wrote: > > * tables can be defined in some intermediate way, but the resulting distribut- > > ed "POD" visible via "perldoc" would be a neat ASCII table contained in a > > verbatim section. And this preformatted text would be "safe" in all places > > the POD would appear. > > Agree. > > In support of the toolchain concept: > > Given that POD can now contain Unicode, why not allow or encourage > tables using the "Box Drawing" characters (a derivative of what we used > to call the vt100 and IBM PC Line Drawing sets) as shown at > https://unicode-table.com/en/blocks/box-drawing/ > > For example, consider this in perlfaq4.pod: > > Pictures help... Here's the C<%hash> table: > > keys values > +------+------+ > | a | 3 | > | x | 7 | > | d | 0 | > | e | 2 | > +------+------+ > > Why shouldn't this be the nicer-looking: > > Pictures help... Here's the C<%hash> table: > > keys values > ??????????????? > ? a ? 3 ? > ? x ? 7 ? > ? d ? 0 | > ? e ? 2 ? > ??????????????? > > It is true that my (notional) DECwriter LA-36 won't nicely print that, > but even the Linux console does nowadays. It is curious that folks were > widely using line-drawing characters in the late 1970s while Perl's > standard POD today still doesn't. Given a toolchain that creates such > tables in POD files, authors wouldn't even have to look up the gyrations > to type all those funny characters. Is there any argument against this, > when (per "perldoc perlpod") POD can officially contain any > Encode::Supported encoding? > > The same is true if authors want to use Pikchr or *roff's "pic" or "dia" > or whatever to create diagrams and flowcharts; given the > table/image/diagram source code attached to the module, and a > description of the filters used, that keeps distributions reproducible > and modifiable. > > \\/ > -- -- oodler@cpan.org oodler577@sdf-eu.org SDF-EU Public Access UNIX System - http://sdfeu.org irc.perl.org #openmp #pdl #nativeThread Previous | Thread Next