permit non-ASCII characters for rule

[rjbs]

I'd like to use the BOX DRAWINGS characters to get a nice solid set of rule lines in my terminal. It turns out that this isn't entirely straightforward because of how the existing dash and pipe characters are used both to represent themselves and the abstract "rule".

If I do this, it'll likely require a bit of change to how the library represents its own configuration, so I am posting this as a "Shall I proceed?" before proceeding.

[treyharris]

I wasn’t the initial author and I’d have done it differently as well. My work with Raku (and my initial beginnings as a programmer in 90’s-era Haskell) would have pushed me towards a more meta-programmatic approach.

Not to mention, when you raised the staleness issue with me in email and I first took a look, my immediate thought was that there should be an option for Unicode box drawing glyphs.

What is your approach?

I fear two complications, though, not difficult, I think, but ones needing awareness:

1. Interactions with ligature fonts and CJK characters: in both cases we have the length vs. codepoint count vs. glyph vs. width issues. I suspect this will be terminal-emulator-dependent (and possibly font-dependent as well, though I hope not). I hope ligatures are a non-issue (or a non-issue for us, since we can’t do anything about them) since they generally preserve a one-to-one ratio between character count and columnar width. I use a number of terminals and ligature fonts so can test this—I hope if any issues arise they can be abstracted out in a way we can unit test, though!
   If it turns out we need to care, we should probably default to hterm rendering since I think it’s the most widely-deployed (though xterm could be the one Text::FormatTable is actually used in the wild most for given its age).
   I only worry this is an issue at all because xterm especially has certain global-toggling rendering behavior when it moves between 7-bit-clean ASCII, 8-bit-termcode (which right now we just filter out or ignore), and full multilingual UTF output.
2. Other CJK considerations: I can test for Japanese, but I don’t know anything about Chinese or Korean (or Vietnamese, but I’d be astonished if anyone’s using this for Vietnamese Han rendering).

[treyharris]

Oh, I didn’t actually answer your question, hah—I was asking your approach out of curiosity; assuming it doesn’t conflict with what I’m doing to get the library up to modern snuff generally (I’ll post an issue and tracking milestones on that later today and tag you) and incorporating the 3 extant PR’s, I say please, go ahead, and thank you for the courtesy.

[rjbs]

Heya, haven't heard back about this.

I don't know my approach yet, but probably it's "make an attribute or attributes that store/s the characters used for | and - and + and look them up as needed". That will require some disentangling of representation versus meaning issues.

I am holding off on this until I know what's going ahead, and especially with the three outstanding PRs already.