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. \\/Thread Previous | Thread Next