0

Many modern terminal emulators include definitions for box drawing glyphs directly in their own source code, and disregard the versions provided by the font when rendering the display. Is there a general way for a program running in the terminal to detect which glyphs are rendered this way? Specifically, if a program makes use of additional box glyphs that might not be widely supported, what's the best way to check if they're available? Perhaps in terminfo?

My current use case is a small personal-use project written in Python using ncurses for the graphical component, so bonus points for something that plays nicely with those, but I'm interested in all solutions.


EDIT: As an example, here's a set of characters provided by kitty; a comment in the source code indicates they're intended for Powerline integration:

enter image description here

If we try to render the same glyphs in Konsole, though, we get this:

enter image description here

The glyphs displayed by Kitty are defined by the terminal itself, whereas the ones displayed by Konsole are provided by whatever font it's configured to use. Is there a general way for a program running in some arbitrary terminal to detect whether we'll see the something like the former vs. the latter?

4
  • 1
    I am not sure I fully understand your question. Do you mean you are running some ncurses-linked program in some Xterm and want to know it the Xterm will be capable of rendering the ACS_* (as defined in docs.python.org/3/library/curses.html in the Constants section) characters appropriately ?
    – MC68020
    Commented Nov 4, 2022 at 8:31
  • @MC68020 In this case, I'm using kitty; when compiling from source, it's fairly easy to add support for additional box glyphs, so I threw in a few custom ones that make things pretty, but aren't strictly necessary for my project. For portability's sake, I'd like to have the option to use my app in a terminal that doesn't support these extra glyphs, so I'm looking for the best way to check if they're available and, if not, replace them with a less-pretty option from the standard character set, if that makes sense? Commented Nov 5, 2022 at 4:01
  • @MC68020 It's also worth adding that this isn't (necessarily) specific to my narrow use case. For example, the "stock" version of kitty also includes a few extra box-drawing characters designed to work nicely with powerline fonts. Konsole, on the other hand, doesn't seem to support them, and instead displays the (completely unrelated) characters contained in the font—not that any of that is relevant to my current problem, I just bring it up as an example of why this question might have broader applicability. Commented Nov 5, 2022 at 4:11
  • @MC68020 I've edited the original question with some screenshots, hopefully that helps clarify. Commented Nov 5, 2022 at 4:31

1 Answer 1

0

You're apparently using characters that are part of the Unicode 1.0.1 Private Use Area. Box-drawing characters in this area are not really standardized, but are used by the powerline plugins for the vim editor, certain shells and other command-line tools.

See this question on Superuser.SE for more information.

It appears the developer of KiTTY may be an user of the powerline plugins, and has implemented support for their box drawing characters directly into the terminal emulator.

As far as I know, there is no standard programmatic way to test for the availability of the powerline box-drawing characters: you will need to check the feature list of your terminal emulator, and if it does not include a direct powerline support, use a powerline-patched font.

The classical way to use line-drawing characters on Unix-style terminals (and terminal emulators) would rely on the terminfo smacs/rmacs and acsc values. smacs and rmacs are control codes to switch into and out of line-drawing mode, and acsc describes the characters to use. Some software might also use PC default codepage #437's box-drawing characters, but that usually requires a font-switching capability and a font with the correct character set.

The modern way would be to use the Unicode standard box-drawing characters, in the range 0x2500-0x257f. Whether those are provided by the font or directly by the terminal emulator should be an implementation detail that has no significance to the application.


Personally, I find powerline and similar terminal configuration hacks typical products of a certain development stage of Unix/Linux power users, similar to the larval stage of programmers described in the Jargon File.

Once exposed to the realities of working as a group of system administrators maintaining tens or hundreds of systems, desires to intensely customize the terminal environment tend to pass, and be replaced by the ability to seamlessly work with whatever is the standard or factory default setup of the systems you most commonly come across. One might still have certain preferred customizations, but they tend to get pared down to a hard core of important functionality at the expense of fancy looks.

Perhaps this helps you understand why some might not find powerline and similar fancy terminal displays very important.

2
  • Thank you for the thoughtful answer. That said, as I stated in my original question, "My current use case is a small personal-use project...", and if you read my comments responding to MC68020 above, I explain the motivation in slightly more detail. I'm not actually using powerline for anything; I included those screenshots as a way illustrate the problem without getting too bogged down in my own project's details. I've accepted your answer, as it does indeed answer the question, but with all respect, I really don't appreciate the condescending tone of your last 3 paragraphs. Commented Nov 5, 2022 at 11:38
  • (Incidentally, I did end up finding a solve/workaround for the problem I'm having, albeit one so narrowly applicable my situation that I don't really think it's worth writing up) Commented Nov 5, 2022 at 11:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .