| Newsgroups |
gmane.text.unicode.general |
| Message-ID |
<[email protected]> |
Dnia 26 grudnia 2025 01:44 Jim DeLaHunt via Unicode <[email protected]> napisał(a): On 2025-12-25 09:40, [email protected] via Unicode wrote: In
L2/98-354 ( www.unicode.org 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 ( www.unicode.org 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 urldefense.com DEC
Technical Character Set (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 urldefense.com DEC Technical Character Set (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 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. 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. In VT330/VT340 Programmer Reference Manual ( bitsavers.org 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 l ike 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. 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. 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./