4 ms·

I love these ideas because i love term... BUT... i really feel like we need variable font sizes in terminals. .. or something, i'm not an expert. I love so man

I love these ideas because i love term... BUT... i really feel like we need variable font sizes in terminals. .. or something, i'm not an expert. I love so many term features but they're at odds with me when i have a larger font size. Suddenly by having my coding text slightly larger i lose screen real estate because all of my borders and widgets are big font characters too. Is there a good way to have bigger primary font with smaller TUI borders/widgets/etc? What would a good way look like?

auggierose 5y ago
You mean, a GUI?
- lijogdfljk 5y ago
  I'm sure you're being sarcastic, but no - i mean a TUI. Hypothetically some simple restrictions for variable font sizes could keep the simplicity of TUI while also empowering the UX. Similar to how variable colors didn't suddenly make this a "GUI".
  - auggierose 5y ago
    Yup, being sarcastic, you got me there. Like, a variable font size such that a letter can be just one pixel high and wide? Yeah, that's a GUI. But I rather prefer GPU accelerated GUIs ;-)
    - lijogdfljk 5y ago
      No, not at all a pixel wide. A pixel wide font character can hardly be called a character, can it? What information does that pixel character convey, exactly? Would it not look identical? Instead, this is the largest failing in my mind to TUIs. As eyesight goes, font sizes increase, and if you use a TUI so do your borders, pads, etc. You have no way to keep a reasonably consistent border size in a TUI if you also want larger fonts. As it stands i'd prefer my "UI" elements in my TUI to be half the size they are currently. Gutters for things like line numbers or error indicators are obscenely wide due to this notion that they must be a full block size. If instead you put restrictions on the division, such that font blocks would have to evenly divide then, hypothetically, misalignment would be less of a concern. So many cool new TUIs are being born today but without very small font sizes they are made nearly useless imo. Popups in https://zellij.dev/ https://zellij.dev/ are another great example of something severely inhibited by old fashioned limitations.
  - dragonwriter 5y ago
    > Hypothetically some simple restrictions for variable font sizes could keep the simplicity of TUI while also empowering the UX. The only way variable font sizes work without being isomorphic to a GUI is if the sizes are a series of power-of-N multiples of some base size for some integer N. (Realistically, N=2 is the most likely, though N=3 might sometimes make sense.) The reason for power of N is that it assures that any set of available sizes used still fit on a grid of the smallest size actually used.
    - lijogdfljk 4y ago
      Yup i mentioned exactly that below, this is what i was thinking as well. It does seem to add reasonable complexity to the implementations, but i imagine it's opt-in.
BeFlatXIII 5y ago
Are you thinking of 16pt vs 14pt or are you asking for double-height letters and/or giant box art headers?
- lijogdfljk 4y ago
  I mentioned in another post, and as someone else also mentioned, that it would hypothetically work well if you kept the sizes at multiples. Ie i wouldn't want to break the grid and break alignment, so vertically a smaller font size would go in multiples, such that each downward increment of font would be half the size. Makes it a bit more complex though if the block sizes make subdivision like this difficult, though. This isn't an idea for an implementation necessarily, rather just an idea to illustrate my request. I want to have larger font size than my gutters/etc in my term editors.
iamevn 4y ago
At the very least double height, double width, and double size letters are specced out but are unfortunately not supported by enough terminal emulators that I'd use them for more than a toy.

auggierose 5y ago

You mean, a GUI?

lijogdfljk 5y ago
I'm sure you're being sarcastic, but no - i mean a TUI. Hypothetically some simple restrictions for variable font sizes could keep the simplicity of TUI while also empowering the UX. Similar to how variable colors didn't suddenly make this a "GUI".
- auggierose 5y ago
  Yup, being sarcastic, you got me there. Like, a variable font size such that a letter can be just one pixel high and wide? Yeah, that's a GUI. But I rather prefer GPU accelerated GUIs ;-)
  - lijogdfljk 5y ago
    No, not at all a pixel wide. A pixel wide font character can hardly be called a character, can it? What information does that pixel character convey, exactly? Would it not look identical? Instead, this is the largest failing in my mind to TUIs. As eyesight goes, font sizes increase, and if you use a TUI so do your borders, pads, etc. You have no way to keep a reasonably consistent border size in a TUI if you also want larger fonts. As it stands i'd prefer my "UI" elements in my TUI to be half the size they are currently. Gutters for things like line numbers or error indicators are obscenely wide due to this notion that they must be a full block size. If instead you put restrictions on the division, such that font blocks would have to evenly divide then, hypothetically, misalignment would be less of a concern. So many cool new TUIs are being born today but without very small font sizes they are made nearly useless imo. Popups in https://zellij.dev/ https://zellij.dev/ are another great example of something severely inhibited by old fashioned limitations.
- dragonwriter 5y ago
  > Hypothetically some simple restrictions for variable font sizes could keep the simplicity of TUI while also empowering the UX. The only way variable font sizes work without being isomorphic to a GUI is if the sizes are a series of power-of-N multiples of some base size for some integer N. (Realistically, N=2 is the most likely, though N=3 might sometimes make sense.) The reason for power of N is that it assures that any set of available sizes used still fit on a grid of the smallest size actually used.
  - lijogdfljk 4y ago
    Yup i mentioned exactly that below, this is what i was thinking as well. It does seem to add reasonable complexity to the implementations, but i imagine it's opt-in.

BeFlatXIII 5y ago

Are you thinking of 16pt vs 14pt or are you asking for double-height letters and/or giant box art headers?

lijogdfljk 4y ago
I mentioned in another post, and as someone else also mentioned, that it would hypothetically work well if you kept the sizes at multiples. Ie i wouldn't want to break the grid and break alignment, so vertically a smaller font size would go in multiples, such that each downward increment of font would be half the size. Makes it a bit more complex though if the block sizes make subdivision like this difficult, though. This isn't an idea for an implementation necessarily, rather just an idea to illustrate my request. I want to have larger font size than my gutters/etc in my term editors.

iamevn 4y ago

At the very least double height, double width, and double size letters are specced out but are unfortunately not supported by enough terminal emulators that I'd use them for more than a toy.