Skip to content
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

Open
gaussandhisgun opened this issue Dec 27, 2024 · 3 comments
Open

Add U+25E4 and U+25E2 to sprite face #3344

gaussandhisgun opened this issue Dec 27, 2024 · 3 comments
Labels
font Issue within the font stack (typically src/font)

Comments

@gaussandhisgun
Copy link

So my shell prompt uses these two characters: Black Upper Left Triangle U+25E4 ◤ and Black 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?)

Image
The terminal on the bottom right is blackbox-terminal

@qwerasd205
Copy link
Collaborator

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 (U+E0BC, upper left triangle) and (U+E0BA, lower right triangle) which should be properly stretched.

@mitchellh mitchellh changed the title LibVTE and triangles Add U+25E4 and U+25E2 to sprite face Dec 27, 2024
@mitchellh mitchellh added the font Issue within the font stack (typically src/font) label Dec 27, 2024
@mitchellh
Copy link
Contributor

Renamed issue to focus on adding these codepoints to our sprite face.

@Wukuyon
Copy link

Wukuyon commented Dec 31, 2024

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.

@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:

In discussions about inclusion of full-height triangles for this purpose, the unicode consortium rejected inclusion of full-height TRIANGLES in the "legacy computing" extension. Their argument was that they were pre-existing in 25E2-25E5 and that unicode does not specify a glyph's particular representation in a font, merely the MEANING.

@hpjansson also explains in this Chafa blog post:

Unicode 13.0: The standard has a few annoying issues, such as not declaring any code points for the four permutations of black triangle, relying instead on existing code points in the geometric shapes block (U+25E2..U+25E5) which are typically represented by fonts as sitting on the baseline surrounded by empty space and therefore useless next to the legacy computing and block elements blocks.

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 (◸ ◹ ◺ ◿). The outline triangles should fill their whole character blocks' heights without seams, too.

Thanks for everyone's hard work on Ghostty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
font Issue within the font stack (typically src/font)
Projects
None yet
Development

No branches or pull requests

4 participants