For regular mathematics we have encoded some glyph pieces that can be used to construct large sizes of sigma, brackets or fences.
They don't rely on a specific layout mechanism, in fact they may not even be serialized in the text stream. To me, it would make sense to unify these with their terminal equivalents which would then require an emulator to serialize them properly and to use a font where the glyph pieces line up. There could be an issue with that approach if the way the symbol is broken into pieces is different enough that a unification can't work on a logical level, even with a dedicated font. If there are pieces that don't map well to existing ones it might be sensible to encode whichever ones can't be mapped. Any documents requesting that need fully worked out examples. A./ On Thu Dec 25 16:38:27 PST 2025 Jim DeLaHunt via Unicode wrote: On 2025-12-25 09:40, [email protected] (mailto:[email protected]) via Unicode wrote: > In L2/98-354 ( > > > > > https://www.unicode.org/L2/L1998/98354.pdf > > ), the following characters were proposed for DEC Technical Character Set > compatibility: > > * E0AE Right ceiling corner DEC Tech 03/05 > * E0AF Right floor corner DEC Tech 03/06 > > However, in L2/00-159 ( > > > > > https://www.unicode.org/L2/L2000/00159-ucsterminal.txt > > ) which was incorporated into Unicode 3.2, those characters were withdrawn: > > E0AE Right ceiling corner U+2309 (1) E0AF Right floor corner U+230B (1) > (1) These characters were in Unicode all along, but the shape shown in the > Unicode book was different from the shape on the terminal. However, this is > not sufficient reason to have two versions of the same symbol. > > However, in > > DEC > Technical Character Set ( > (https://urldefense.com/v3/__https://vt100.net/charsets/technical.html__;!!BDUfV1Et5lrpZQ!Sz6zze1z-M_LTSPW0rIIzWUQNelFKnVEyxjuZ9heR5jLaL5gUpYG6I0qDcmkLRMrcElIb4gqD0QQLkFGildA6qyV$) > > > vt100.net (http://vt100.net) > > ) the usage of those characters is explained as being parts of the summation > symbol, and the left side of those characters connect to U+2500. > > As far as I know, the floor and ceiling symbols usually have similar height > to brackets (with the horizontal stroke being on bottom or top of the bracket > height), and are used in pairs of left and right glyphs, which is completely > different from the DEC Tech 03/05 and DEC Tech 03/06 characters. Is there any > typographical precedent of floor and ceiling symbols being used with a > centered horizontal stroke or with a horizontal connection to other > characters? The idea of "typographical precedent of floor and ceiling symbols being used with a centered horizontal stroke" seems to me a non-sequitur from the content at DEC Technical Character Set ( (https://urldefense.com/v3/__https://vt100.net/charsets/technical.html__;!!BDUfV1Et5lrpZQ!Sz6zze1z-M_LTSPW0rIIzWUQNelFKnVEyxjuZ9heR5jLaL5gUpYG6I0qDcmkLRMrcElIb4gqD0QQLkFGildA6qyV$) vt100.net (http://vt100.net) ). The latter alludes to a 2-d layout system by which parts of a sigma sign is assembled from eight graphical components to make a 2x3 or 3x5 composite graphic. The former talks about formatting of linear plain text with general-purpose fonts. I can see the benefit of providing a mapping between the code units in the DEC TCS and Unicode. I don't think that implies that ordinary plain text and text formatting mechanisms should be able to perform the 2-d layout described by DEC TCS. If I were implementing DEC TCS in a modern OS and app, I would either use graphics mechanism to draw the sigma, or an app-specific font where the glyphs have the size and relationships which the app requires. Does this answer your question? Or, reject the premise helpfully? Best regards, —Jim DeLaHunt
