Re: Pd: Odp: Re: DEC Technical Character Set summation symbol corners

On 2025-12-25 23:32, [email protected] via Unicode wrote:

>
> Dnia 26 grudnia 2025 01:44 Jim DeLaHunt via Unicode 
> <[email protected]> napisał(a):
>
>     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
>>     <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
>>     <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 (vt100.net)
>>     <https://urldefense.com/v3/__https://vt100.net/charsets/technical.html__;!!BDUfV1Et5lrpZQ!Sz6zze1z-M_LTSPW0rIIzWUQNelFKnVEyxjuZ9heR5jLaL5gUpYG6I0qDcmkLRMrcElIb4gqD0QQLkFGildA6qyV$> 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
>     (vt100.net)
>     <https://urldefense.com/v3/__https://vt100.net/charsets/technical.html__;!!BDUfV1Et5lrpZQ!Sz6zze1z-M_LTSPW0rIIzWUQNelFKnVEyxjuZ9heR5jLaL5gUpYG6I0qDcmkLRMrcElIb4gqD0QQLkFGildA6qyV$>.
>     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
>
>
>
> The proposal L2/00-159 was intended to introduce support of the DEC 
> Technical Character Set and some other legacy sets. Since U+23B7 
> RADICAL SYMBOL BOTTOM (only attested in DEC Technical) was accepted in 
> Unicode 3.2, it then implies that Unicode itself is intended to 
> support the DEC Technical Character Set.
I think you have a meaning of "support" which is perhaps more broad than 
my understanding. I am not familiar with the details of the decisions 
around L2/00-159. What I take from this email thread is that the Unicode 
Standard provides a bidirectional mapping between glyph codes in the DEC 
TCS and Unicode scalar values. That does not imply that plain Unicode 
text and general-purpose fonts and ordinary text layout engines can 
reproduce the behaviour of DEC TCS systems.
> In that proposal, it is implied that 03/05 and 03/06 are mapped 
> to U+2309 and U+230B (⌉⌋). If, as you claim, 'The idea of 
> "typographical precedent of floor and ceiling symbols being used with 
> a centered horizontal stroke" seems to me a non-sequitur', this seems 
> to imply that the mapping is inappropriate, which is what I'm 
> concerned with.
You keep making implications. How about sticking to the plain meaning of 
words? To me, your reference to "typographical precedent" does not 
follow from your earlier reference to the list of DEC TCS glyph codes.
>
> In VT330/VT340 Programmer Reference Manual 
> (http://bitsavers.org/pdf/dec/terminal/vt340/EK-VT3XX-TP-001_VT330_VT340_Text_Programming_Mar87.pdf, 
> page 27; page 41 of 348 in pdf), the list of individual characters is 
> shown, implying that like many legacy computing platforms, DEC 
> Technical Character Set uses a grid of independent character cells, 
> where each character tile may be set to a separate character.…

Note that a "grid of character cells" is a two-dimensional layout of 
glyphs. That is different from the Unicode character-glyph model and 
plain text. If a system wants to reproduce VT330/VT340 behaviour, it 
needs to layer a higher-level protocol on top of Unicode plain text. So, 
don't expect Unicode plain text and character-glyph models to reproduce 
a VT330.  And, the higher-level protocol can specify use of a font which 
has the glyph shapes and alignments that fit the VT330 behaviour.

> There is no mention of any 'graphics mechanism to draw the sigma', so 
> that is off topic to use.
>
> Using 'an app-specific font where the glyphs have the size and 
> relationships which the app requires' is supposed to work in theory, 
> but there is the problem of deciding what mapping to use.

That is the task of the higher-level protocol. I think you should not 
expect the Unicode plain text model to determine that.

Best regards,
      —Jim DeLaHunt

>
> Dnia 26 grudnia 2025 02:11 asmusf--- via Unicode 
> <[email protected]> napisał(a):
>
>     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.
>
> The bracket portions in DEC Technical are already unified with their 
> STIX equivalents. The top left and bottom left portions of summation 
> symbol in DEC Technical are already unified with the summation top and 
> bottom halves. What I'm asking about is the top right and bottom right 
> corners, which the L2/00-159 proposal did not identify as portions of 
> summation symbol at all, and likely misidentified the character.
>
>     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.
>
> In this case, the top right and bottom right corners of summation 
> symbol being different enough from ceiling and floor symbols.
>
>     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./
>
>
>
>
>
>
>
-- 
.   --Jim DeLaHunt,[email protected]     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant, Vancouver, Canada