From vt100.net https://vt100.net/charsets/technical.html it appears that a possibly intended grid is the following: 03/01 02/03 03/05 03/03 03/07 03/04 03/02 02/03 03/06 And by checking the proposals to see how those characters were intended to be mapped to Unicode: 03/01, 03/02: L2/98-354 maps them to private use E0AD and E0AC, then L2/00-159 remaps to STIX summation symbol halves U+23B2 and U+23B3 respectively (the proposals do not acknowledge any usage of other portions of the summation symbol) 02/03: L2/00-159 mentions it as U+2500 or U+23AF 03/03, 03/04: not mentioned in the proposals, but www.columbia.edu www.columbia.edu/kermit/ftp/charsets/dectech.txt names them as 'Upper left to lower right diagonal line' and 'Upper right to lower left diagonal line', most likely referring to existing U+2572 and U+2571 respectively 03/05, 03/06: L2/98-354 maps them to private use E0AE and E0AF, then L2/00-159 remaps to existing ceiling/floor symbols U+2309 and U+230B respectively 03/07: not mentioned in the proposals, but www.columbia.edu www.columbia.edu/kermit/ftp/charsets/dectech.txt names it as 'Ket (Large right angle bracket)', most likely referring to either U+232A or U+3009 (as U+27E9 did not exist at the time) Dnia 26 grudnia 2025 09:41 Asmus Freytag via Unicode <[email protected]> napisał(a): From a quick glance, it looks like Unicode so far has one fully formed glyph piece for top and bottom each for the summation symbol. They are enocoded at U+23B2 and U+t23B3. These are intended to allow a two-story sigma, but not an infinitely large one (unless you use an OpenType font that scales stroke width down in relation to height for larger font sizes). The Dec Character set appears instead to have the left / right corners for the top and bottom of the summation symbol encoded separately which would allow a wider top or bottom. There's also a piece that looks like a shallow right-pointing V, which sets this up for a three-story symbol. If the DEC Technical top left and bottom left corners (03/01 and 03/02) were used for a 2-line summation symbol, then the centering of the horizontal strokes has the effect of making the overall 2-line summation have the black-body height of the sum of line height and stroke weight, and the additional diagonal connections that cause the middle corner to end up on the right edge, which could be considered a font-level variation where the summation halves also happen to be usable for larger connections, similarly to how arrow characters may or may not have to connect to bounding box edges depending on the compatibility scenario. The 'shallow right-pointing V' (which is 03/07) has diagonal connections that also occur in the Ohio Scientific character set, resulting in it being proposed in L2/21-235 and incorporated in Unicode 16.0 as U+1FBDB BOX DRAWINGS LIGHT DIAGONAL UPPER LEFT TO MIDDLE CENTRE TO LOWER LEFT. Additional diagonal pieces seem to have the correct angle to allow both a 3 story and a 5-story summation symbol. This of course, would be wider than a character cell, so the top and bottom are broken apart, so they can be wider in a monospaced font. That the horizontal lines with the down/up tick at the right end are supposed to extend to top/bottom bar on the sigma, with the ticks being the "serifs" on the Sigma may not have registered because they simply look like rotated floor / ceiling style symbols. I don't think there is any rotation involved (it wouldn't make sense given the character grid). The proposals L2/98-354 and L2/00-159 do not acknowledge usage of other characters than 03/01 and 03/02 to form the summation symbol, so the identification of 03/05, 03/06 as ceiling/floor symbols could be a result of incomplete information on the usage of the characters. So the summation symbol pieces would seem to be set up out of the box for a five story design that is two cells wide. What is encoded in the 2300 block is two stories tall and one cell width (unless Opentype tricks are used to make the pieces larger without changing the stroke width, but if you can do that, you wouldn't need pieces in the first place). The existing characters cannot be used for a design that uses glyph pieces to give a five story x 2 cells design. Due to the diagonal connections there would have to be at least 3 columns for a 5-row summation symbol. It would help if any proposal documents actually showed the assembled symbols / preferably in the context of a sample formula. Showing just the character set is not as helpful. And it would be useful to show an attempt to do the same with the characters already encoded in the standard to show the difference in design of hte glyph piece set for 2-story vs. 3 or 5 story designs. A./ Such a proposal would also have to assess potential candidates for unification: — U+2309 and U+230B: this is what 03/05 and 03/06 were identified as in L2/00-159, but the typical usage of bracket sized symbols is completely different from the corners of summation symbol and likely a mutually exclusive usage — U+231D and U+231F: I'm not sure exactly what the usage of those corner characters is, or whether centering of horizontal stroke and horizontal connections to other characters is allowed — U+2510 and U+2518: those definitely cannot be used, as they are used in DEC Special Graphic Character Set and connect to bottom or top edge, having a distinct appearance (and in bitsavers.org http://bitsavers.org/pdf/dec/terminal/vt340/EK-VT3XX-TP-001_VT330_VT340_Text_Programming_Mar87.pdf it is mentioned that DEC Special Graphic and DEC Technical sets may replace GL or GR sets, implying the possibility of the two coexisting in the same document if one is used in GL and the other in GR) — U+1CC1C and U+1CC1B: those are Sharp MZ compatibility characters, but connect on both left and right and to bottom and top edge, so it is unlikely to be usable for summation corners
Re: Pd: Odp: Re: DEC Technical Character Set summation symbol corners
[email protected] via Unicode Fri, 26 Dec 2025 02:18:30 -0800
- Pd: Odp: Re: DEC Technical Character Set ... [email protected] via Unicode
- Re: Pd: Odp: Re: DEC Technical Chara... Jim DeLaHunt via Unicode
- Re: Pd: Odp: Re: DEC Technical C... [email protected] via Unicode
- Re: Pd: Odp: Re: DEC Technic... Asmus Freytag via Unicode
- Re: Pd: Odp: Re: DEC Technical Chara... Asmus Freytag via Unicode
- Re: Pd: Odp: Re: DEC Technical C... [email protected] via Unicode
- Re: Pd: Odp: Re: DEC Technic... Asmus Freytag via Unicode
