Black Right-angled triangles (U+25E2 - U+25E5)

[Logo121]

I noticed that in PhMajerus's graphic block template thing in issue #2210, there is this "Triangles" set:

Where the characters ◥◢◣◤ are used as half-cell fillings.

Indeed, if we refer to the Unicode chart, the shaded triangles, which definitely extend to the whole cell, they also point to these 4 characters as a related character:

and for FairfaxHD, they treat these 4 as extending to the cell as well (as they are mapped to PETSCII and ATASCII):

But does that mean the half-cell version is the correct one? Maybe not: From an old unicode proposal, it was suggested that:

It can be inferred from the Unicode 2.0 and 3.0 books that U+25E4 does NOT extend to the edges of the cell, since its vertical and horizontal edges are the same length as Black Square, U+25A0, which is contrasted with (and smaller than) Full Block, U+2588.

(though the half-cell wedges are ultimately merged to those 4 characters anyway), while the Wingdings mapping seems to map the 4 half-■ characters to the same codepoints. This suggests that both the existing glyphs and the ones in FairfaxHD are actually correct representations.

---

So the possible solutions are to:

1. Choose either one as the "canonical" representation and ignore the other mapping. If this is the case it is probably better for the current glyph to be changed to the half-cell one, considering there are some practical usage for them (i.e. as semigraphics)
2. Create a new variant feature for choosing between the "stretch to cell" and "restrict to square" forms. There are actually a few characters in the new proposed block that may benefit from these (e.g. ), since the source are mostly small, square-celled fonts where the correct rectangular-cell representation can be ambiguous. Though these applications are mostly just "good to have" with no attested usage or need.

[jmcwilliams403]

I feel like this is mostly just a quirk of the original unicode proposal as a consequence of trying to unify as many legacy characters as possible with existing characters.

For example, in both Atascii and Petscii, there is a character that clearly resembles ● (black circle) because it's the same size as a character that's unified with ○ (white circle) but the former is instead unified with • (bullet) to match the existing character ◘ (inverse bullet), rather than try to encode a separate hypothetical "inverse black circle" character, which is often encountered as a graphical variant of the existing negative bullet character in various legacy encoding standards.

I feel like modifying an existing glyph that already has a stable modern form would basically specifically favor Atascii and Petscii over the many other systems that use the current glyph, and it would be impractical to try to satisfy everything at once due to the mutually incompatible interpretations of these characters across all standards.

[be5invis]

Creating a feature for this should work better. You can add a Gr first then an OT feature.

[jmcwilliams403]

Creating a feature for this should work better. You can add a Gr first then an OT feature.

For what it's worth, the powerline PUA block contains some existing character-cell-justified triangle glyphs that could be copied over verbatim for this.

[PhMajerus]

This is a difficult choice, and Unicode has several other characters where it is unclear whether they should extend to the full-block boundaries or be kept square in non-square fonts.

I think it all comes from the fact that on 8-bit computers, there was usually a single characters ROM for both square and rectangular fonts, basically when you changed the text mode to handle different numbers of columns and rows, the characters would just get stretched accordingly. Unicode made their charts with somewhat square characters, and now we have many non-square fonts that assumed these symbols should be kept square and just get centered.

The existing triangles ▼, ◀, ▲, and ▶ are facing the same problem as they are also reused for legacy computing compatibility where they should extend to the full-block size.
And the same goes for ◶, ◵, ◷, ◴, ◒, ◑, ◐, ◓, ◲, ◱, ◳, ◰, ◩, ⬒, ⬔, ◧, ◨, ⬕, ⬓, ◪, and I'm sure some others I'm forgetting.

I think there is unfortunately no correct solution, and legacy ansi-art imported from those computers, while being now possible to convert to Unicode, will probably need a special font to render as intended.

It gets even worse with the Unicode 16, where they included all of Apple II MouseText characters, except the ⌛ hourglass, as it already exists at U+231B… except that while it has the same general meaning, the one in MouseText is supposed to be single-width and monochrome, not a double-width emoji:

So there is no pleasing everyone, and even an appropriate Apple II font may not be able to fix it in terminals that assume that character to always be double-width.

Oh, and btw, U+25C6:◆ doesn't look right, and you're missing U+2427 (also from Legacy Computing Supplement) to complete the Apple II-specific character set.

[PhMajerus]

Oh, and btw, the triangles ◥, ◢, ◣, ◤ are also part of the new smooth quadrants / diagonal sextants fills.

See the "Diagonals" on the right:

[be5invis]

@PhMajerus You should use Iosevka Term for terminal use as the conventional Iosevka is not conformal to wcwidth metrics.