-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add U+25E4 and U+25E2 to sprite face #3344
Comments
It shouldn't be considered expected behavior for for those characters to stretch to the full cell size, since they're from the "Geometric Shapes" unicode block which are not specified to be cell-fit in any way. That said, we should probably add them to our custom rendering, I don't think it would create any issues for most use cases. For now you can use the powerline characters |
Renamed issue to focus on adding these codepoints to our sprite face. |
@qwerasd205: This isn't entirely accurate. Unicode intentionally unified full-height half-cell triangles with U+25E2..U+25E5. @clort81 explains in adobe-fonts/source-code-pro#301:
@hpjansson also explains in this Chafa blog post:
This reflects the general principle in Unicode that abstract characters are flexible in their glyphs' visual appearances, as long as their "meaning" remains understandable. This applies even to characters in the Geometric Shapes block. It's Unicode compliant for U+25E2..U+25E5 to have flexible appearances varying between "regular" triangles and terminals’ full-height cell-fit triangles, and the Unicode Consortium did in fact unify the full-height cell-fit triangle symbols with U+25E2..U+25E5. This is the reason why even when the Unicode Consortium added a lot of diagonal shapes in Symbols for Legacy Computing, they left out new characters for full-height cell-fit triangles. They considered that job already covered by U+25E2..U+25E5. You can also see this intent to unify full-height triangles with U+25E2..U+25E5 in the official Unicode code chart for the Symbols for Legacy Computing block. The code chart calls out the link between the full-height triangular medium-shade characters U+1FB9C..U+1FB9F and U+25E2..U+25E5. (And Ghostty already renders U+1FB9C..U+1FB9F as full-height triangles.) It's therefore correct to render U+25E2..U+25E5 as full-height half-cell triangles for terminals. The Unicode Standard means for these encoded characters to be used for this purpose. And these full-height triangles are essential for PETSCII-style semigraphics and text art. So because Unicode purposefully encodes no other characters for that job, it's impossible to render PETSCII-style semigraphics and text art without rendering U+25E2..U+25E5 as full-height triangles. Note also that the Kitty terminal already renders U+25E2..U+25E5 as full-height triangles. So do the Unscii and GNU Unifont fonts. One more thing to add: there are also outline versions of the filled triangles in the same Geometric Shapes block, U+25F8..U+25FA, and U+25FF ( Thanks for everyone's hard work on Ghostty. |
So my shell prompt uses these two characters:
Black Upper Left Triangle
U+25E4
◤ andBlack Lower Right Triangle
U+25E2
◢, from Unicode 1.1. LibVTE terminals (so, usually, terminals made with GTK in mind, like xfce4-terminal, blackbox, kgx) stretch triangles from this block to fit the "cell" they are occupying. And it was kind of weird for me to open up ghostty, fully expecting it to behave like any other GTK terminal on my system, and see it behave like Kitty with a GTK title bar (which, i guess, it is?)The terminal on the bottom right is blackbox-terminal
The text was updated successfully, but these errors were encountered: