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./
