search

cjbassi / ytop

A TUI system monitor written in Rust
MIT License
2.16k stars 84 forks source link

Graphs in Braille patterns do not always work as expected #79

Open ssb22 opened 4 years ago

ssb22 commented 4 years ago

ytop is trying to draw graphs by using the Braille Patterns Unicode block (U+2800..U+28FF). Unfortunately, when I install ytop on a Fedora 32 system as described in Fedora Magazine and run it in Gnome Terminal, with font set at "Monospace Regular" in Gnome Terminal Preferences, the Braille Patterns show not only the "on" dots as solid circles, but also the "off" dots as hollow circles. The presence of those "off" dots renders the graph significantly less readable (see screenshot below).

Obviously ytop has little control over the font in use by the terminal, but it would be nice if there were an option to use low-resolution block graphics instead of Braille patterns, in case anyone is stuck with a font that does not show the Braille patterns as you'd expect. It would also be nice to have something in the documentation giving advice about which terminal fonts are known to work well for ytop graphs, especially if some popular distributions are going to default to a font that doesn't work so well. image

Required information:

Include any of the following information if relevant:

Please copy or attach ~/.local/state/ytop/errors.log if it exists and contains logs: n/a

cjbassi commented 4 years ago

I agree it might be good to have an option to switch to a different rendering character and/or include something in the documentation about fixing the fonts. Note that this is the same issue as https://github.com/cjbassi/gotop/issues/18, and it seems that many people were able to figure out how to fix their font so we could probably add something to the readme about how to do that.

gbrlsnchs commented 4 years ago

I think I can't work around this when using unifont with Alacritty... there's no glyph overriding with it. :disappointed:

TheLazyist commented 4 years ago

I currently have the same issue? how did you guys remove it?

deionizedoatmeal commented 4 years ago

@TheLazyist you don't happen to be using kitty do you? When I was experiencing this issue on kitty I managed to resolve it by installing the tff-symbola package from the AUR and then adding this line to my kitty.conf:

symbol_map U+2800-U+28FF Symbola

If you're using a different terminal emulator you could just try installing the package and seeing if that helps.

ssb22 commented 4 years ago

OK so on Fedora 32 with sudo dnf install kitty gdouros-symbola-fonts and entering kitty and pressing Control-Shift-F2 to edit the configuration, and adding the suggested line

symbol_map U+2800-U+28FF Symbola

save, and kitty ytop works as designed. Perhaps the Fedora Magazine article on ytop should have told us to get Kitty as well☺

I still think it would be nice to have an alternative rendering option (in case Kitty is not available for some reason) and/or documentation.

felix91gr commented 4 years ago

I would love for there to be an alternative rendering option, for two reasons:

  1. When zooming out, you can see an aliasing pattern of horizontal lines in the zoomed out graphs. This might be fixable with some antialiasing in a rendering stage previous to character printing, but I'm not certain.
  2. I use ytop in a server with 8 cores, and when their graphs overlap, one of the graph lines shadows all the others. I would like for this edge case to still show all lines, but that would probably require drawing finer lines. For this, a lower-level graphing solution seems ideal.
CosmicHorrorDev commented 4 years ago

I'm not sure what you're referring to with 1. 2 would involve switching the frontend away from the TUI, and while separating the current frontend and backend should be mostly trivial. Writing a new frontend would be a totally separate project.

felix91gr commented 4 years ago

Oh, sorry, I'll post a picture to show (1).

Re: new frontend. I'm guessing the frontend is basically one of the crates that allow one to draw on the terminal, right? If so, I completely understand - that kinda library is... well, as you said, worthy of being an entire project by itself

CosmicHorrorDev commented 4 years ago

Correct. The current frontend is tui which is also why it would be quite hard to fix text rendering issues because those are primarily caused by individual people's terminal settings. For example I don't have any problems with the braille patterns because my font doesn't display the lowered dots. And if someone's terminal only supported ASCII then they will have problems as well. But AFAIK that's separate from this program entirely and just shows issues from users setups.

It would be nice to add ASCII support I suppose, but you lose a lot of detail that's provided with the variety of UTF8 characters.

felix91gr commented 4 years ago

Yeah, no, that makes complete sense. Also, UTF-8 for the win.

@LovecraftianHorror as promised, here's a picture of (1):

image

See what I mean? I think that is caused because the braille patterns aren't seamless with one another vertically. Somehow y'all (or tui's?) made it seamless horizontally, which looks frankly fantastic. But the vertical seams are... mm, they bother me a lot when looking at zoomed-out graphs. I would much prefer if that spacing was reduced so that the horizontal lines appeared to be continuous with one another :slightly_smiling_face:

felix91gr commented 4 years ago

PS: I wish one could change the colors of the individual dots. That way I could suggest a way to solve (2) without a new frontend

(the idea (in a world where each dot is coloreable) was: (a): blend the colors of all lines that pass through a dot. (b): color each dot with the blended color

Such a technique could also be used for smoothing out the graphs, by taking parts where a dot is partially-covered with a graph, and blending it with the background (this is what is used in many monitors for smoothing out fonts) )

CosmicHorrorDev commented 4 years ago

I see the gap you are talking about now, I never actually noticed it till you mentioned it. I believe the cause of that is that the glyphs for the different braille characters don't fill the whole block vertically which is again a font thing. I highlighted the characters in my chart to show that the characters themselves fit the full height even if the dots don't use it.

image

As far as blending the colors for the lines, that would at the very least require changes in tui since ytop just passes the data for the CPU values to tui without really being able to describe blending the colors (primarily because I think tui is oblivious to a user's color selection as well AFAIK). Granted I haven't delved too far into tui's colorscheme support so maybe there are more features that I'm not aware of, but from what I can tell from here you can only specify the fg and bg color along with different text modifiers.

It would be nice to have features to make the line graphs more digestible, but a lot of the limitations come from this being a TUI: however, a lot of people also use programs like ytop because they are TUIs. Some other programs manage this by showing each cpu individually (htop for example), but that comes at the expense of either taking up a lot of visual space, or losing out on seeing activity over time (which is the choice htop went with). I also believe this is why ytop defaults to showing average CPU instead of individual CPU threads when there are 8 or more CPU threads since it very quickly becomes visually noisey.

Thank you for your suggestions though, they definitely give a good perspective on different features to consider in the future! I hope I didn't come off as dismissive on anything, I just want to make sure you understand the limitations of the current situation. And to be fair I haven't even had a PR accepted for this project yet so it's not like I have any authority over decisions for this project.

felix91gr commented 4 years ago

Thank you for your suggestions though, they definitely give a good perspective on different features to consider in the future! I hope I didn't come off as dismissive on anything, I just want to make sure you understand the limitations of the current situation.

Thank you for this comment. It is reassuring. Communication over text is super hard. I appreciate your feedback even more now :heart:

It would be nice to have features to make the line graphs more digestible, but a lot of the limitations come from this being a TUI

Yeah. I wonder if ytop has access to the font, or the font rendering settings? I bet there's a font with less padding over the braille glyphs than the most common ones.

Btw, great image! The glyph thing you explained looks super clear from here :D

: however, a lot of people also use programs like ytop because they are TUIs.

Indeed! I'm using it because (1) it's pretty AF, I have to say XD, but also, (2) I have a server without GUI, and something like ytop is indeed tremendously useful because all I have there is the terminal :)

Some other programs manage this by showing each cpu individually (htop for example), but that comes at the expense of either taking up a lot of visual space, or losing out on seeing activity over time (which is the choice htop went with). I also believe this is why ytop defaults to showing average CPU instead of individual CPU threads when there are 8 or more CPU threads since it very quickly becomes visually noisey.

All of this makes sense. I personally prefer seeing the graphs overtime, and I think that's why I'm following on ytop to fully replace my usages of htop at some point (or at least using it alongside htop, for just the monitoring).

ssb22 commented 4 years ago

Thanks everyone for looking at this. The tui library documentation says the alternatives to tui::symbols::braille are tui::symbols::bar, tui::symbols::block and tui::symbols::line, so I guess a “ytop for terminals that don't display Braille how we want” would have to use bar or block instead, at a cost of resolution. Whether it's worth the effort I don't know; perhaps it would be best just to document the fonts issue and the recommendation of Kitty.

More generally, I wonder if we should raise (minor) issues on the library projects tui-rs, termui and blessed-contrib suggesting they all add notes to their documentation to say braille mode may not work as you expect if the fonts are set differently and you might want to advise the user of your application to set a font like Symbola in that Unicode range (for example via Kitty's configuration file).

Even more generally, I wonder if we should write some kind of proposal or suggestion to the Unicode Consortium itself, to suggest a variant selector that specifies whether or not the “off” dots are to be shown in the Unicode Braille Patterns block.

The Braille Patterns block was originally designed for representing Braille, for example in books that help sighted readers to learn how Braille works. So for example the New International Manual of Braille Music Notation contains copious examples of printed Braille patterns to instruct the sighted reader how to write Braille music. In this context, I find it useful to show the “off” dots in some way (although perhaps not as empty circles—in high-resolution print it makes more sense for “on” dots to be solid circles and “off” dots to be very tiny points, and I usually use the puttinydots option in LaTeX's braille.sty when I'm writing about Braille)—the presence of the “off” dots makes it easier for the sighted person to read exactly which dots are “on”, and not get confused between things like ⠃ versus ⠆ versus ⠘ versus ⠰ which, if shown without “off” dots, all look quite similar when printed in isolation as they might be in an instruction book about Braille transcription. Therefore I am generally supportive of the idea of fonts including the “off” dots for use in Braille instruction manuals. But, although Unicode's official PDF file does show the “off” dots (albeit as circles instead of my preferred “tiny dots”), it also says these glyph shapes are “not prescriptive”. Some fonts have chosen not to show the “off” dots at all, which in turn has led to some terminal-library writers inventing the idea of using Braille Patterns as general graphics, even though this was not their original intended use. This new situation might be considered grounds for having Unicode specify a method for selecting explicitly whether or not we want the “off” dots to be displayed today, instead of leaving this down to our choice of font, since there is a big difference in intent between using a character as an example of Braille and using it as a graphical pattern.

On the other hand, the Unicode Consortium already has a proposal from a “Terminals Working Group” (can anyone figure out how to contact them?) which includes a complete set of 2×3 block graphics from the 1970s UK Teletext service, which could originally be displayed either “contiguously” (no space between dots) or “separated” (small space between dots)—the Unicode proposal acknowledges the “separated” mode but doesn't make clear how to specify it (maybe they're missing a variant selector?), but at least there is no scope for displaying the “off” dots here. If common fonts do begin to include Teletext graphics, it might become a good idea for terminal library writers to provide access to these 2×3 blocks as an alternative to using Braille Patterns as 2×4 blocks. That would mean a 25% drop in vertical resolution (and a slight increase in vertical irregularities if the fonts imitate exactly what was done in the 1970s), but it would unambiguously be block graphics (no question about some fonts showing the “off” dots for instruction manuals). Unfortunately, I suspect the existence of these graphical blocks just might stop the Unicode Consortium from also considering the provision of variant selectors for the original Braille Patterns block, but we won't really know unless we run it past them somehow.