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
