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

Reply via email to