On 12/25/2025 11:32 PM, [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. 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
(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. 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.
From a quick glance, it looks like Unicode so far has one fully formed
glyph piece for top and bottom each for the summation symbol. They are
enocoded at U+23B2 and U+t23B3. These are intended to allow a two-story
sigma, but not an infinitely large one (unless you use an OpenType font
that scales stroke width down in relation to height for larger font sizes).
The Dec Character set appears instead to have the left / right corners
for the top and bottom of the summation symbol encoded separately which
would allow a wider top or bottom. There's also a piece that looks like
a shallow right-pointing V, which sets this up for a three-story symbol.
Additional diagonal pieces seem to have the correct angle to allow both
a 3 story and a 5-story summation symbol. This of course, would be wider
than a character cell, so the top and bottom are broken apart, so they
can be wider in a monospaced font.
That the horizontal lines with the down/up tick at the right end are
supposed to extend to top/bottom bar on the sigma, with the ticks being
the "serifs" on the Sigma may not have registered because they simply
look like rotated floor / ceiling style symbols.
So the summation symbol pieces would seem to be set up out of the box
for a five story design that is two cells wide. What is encoded in the
2300 block is two stories tall and one cell width (unless Opentype
tricks are used to make the pieces larger without changing the stroke
width, but if you can do that, you wouldn't need pieces in the first place).
The existing characters cannot be used for a design that uses glyph
pieces to give a five story x 2 cells design.
It would help if any proposal documents actually showed the assembled
symbols / preferably in the context of a sample formula.
Showing just the character set is not as helpful.
And it would be useful to show an attempt to do the same with the
characters already encoded in the standard to show the difference in
design of hte glyph piece set for 2-story vs. 3 or 5 story designs.
A./
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./
