Dnia 26 grudnia 2025 09:12 Jim DeLaHunt via Unicode <[email protected]> napisał(a): 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] 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. 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. When I
say Unicode 'supports' a character set I mean that Unicode includes all
characters in that character set. 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.… 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. The character
grid itself is different from plain text, but individual characters within that
grid still need to correspond to plain text characters. 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 What exactly does it mean for the mapping
itself to be the 'task of the higher-level protocol'? If there are
multiple different protocols for representing VT330 text with Unicode
characters then they could all use different mappings? Could those mappings
include private use characters? How does that relate to U+23B7 RADICAL SYMBOL
BOTTOM (which is also a DEC Technical compatibility character) being accepted?
