I suspect that falls into “not going there” domain because that is, essentially, colors.
The problem being, in this special case it’s not. (It’s part of the meaning of this combined glyphs – again, compare PETSCII, which relies on this facility for its graphic characters.)
There’s also some application for labels, etc, which is (probably) why there’s the NEGATIVE SQUARED range (which has special glyphs for Latin letter glyphs and figures). Unicode still isn’t able to encode text like it had been possible with ANSI, where you could encode and transfer arbitrary negative text (admittedly, because ANSI had a facility to encode colors).
Did you see this in the 21235r document?
“Reverse video” or “inverse video” characters… have been determined to be out of scope for the UCS and are not proposed here. The ISO 6429 display sequences SGR 7 (“negative image”) and SGR 27 (“positive image”) are suggested as a higher-level protocol to achieve this effect.
I’m aware that it’s considered out of scope, but this is somewhat implicitly contradicted by the existence of the NEGATIVE SQUARED range, which aligns perfectly to negative text. So there was apparently a felt need for this. My observation is that this could have been achieved in a more general and versatile manner by a (combing) modifier without introducing a specialized range of glyphs (which is for Latin letters and principal numbers only). Also mind that this special range somewhat loses or hides the textual meaning, which could be better preserved by the use of a modifier. As it is, without any punctuation and other special characters implemented, the NEGATIVE SQUARED range hardly serves any purpose but the design of very basic textual labels (for which I’ve actually seen it employed). On the other hand, for our special purpose, a modifier would have perfectly suited our needs. (One can still dream.)
Moreover, the ISO 6429 display sequences aren’t implemented for any text or layout software, meaning, there is no way to copy and paste or otherwise transfer this in a sequential manner. IMHO, this decision somewhat seems to miss any case, where a negative image is crucial to the representation of character-based content and the meaning of the glyphs used. Arguably, if there is any case for this, it should be implemented in the string mechanism itself. Otherwise, we will inevitably lose meaning in translation (and preservation).
As we’re at it, there’s still another issue, as I hardly know any font (even including mono-spaced fonts, with the notable exception of dedicated retro computing fonts) where the block and frame characters line up with the rest of the text or even share a common bounding rectangle. So any representation of matrix based character sets is always a bit all over the place with varying base lines and line heights. But this is really out of scope and not Unicode’s fault.
