<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/4/2025 4:35 AM,
<a class="moz-txt-link-abbreviated" href="mailto:piotrunio-2004@wp.pl">piotrunio-2004@wp.pl</a> via Unicode wrote:<br>
</div>
<blockquote type="cite"
cite="mid:abc7589bddea4446aa736e6ff62357ac@grupawp.pl">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div id="gwp597db67c">
<div id="gwp597db67ch">
<div data-color-mode="light" class="gwp597db67cb"
data-message-body="true">
<div>I have investigated the situation further and it seems
that defect in the Unicode 13.0—17.0 mapping is even more
fundamental than I previously thought. In particular, the
proposal L2/25-037 does not acknowledge the proposal
L2/00-159, which had already been incorporated into
Unicode 3.2. In that proposal, the description of
characters U+23B8 (LEFT VERTICAL BOX LINE) and U+23B9
(RIGHT VERTICAL BOX LINE) exactly matches the proposed
characters L2/25-037:1FBFC (BOX DRAWINGS LIGHT LEFT EDGE)
and L2/25-037:1FBFD (BOX DRAWINGS LIGHT RIGHT EDGE). In
both proposals, those two characters are specified to be
aligned to left or right edge, span the entire edge
(extending to the top and bottom), and match the thickness
of Box Drawings Light lines. The description of the
characters U+23BA (HORIZONTAL SCAN LINE-1) and U+23BD
(HORIZONTAL SCAN LINE-9) also exactly matches the proposed
characters L2/25-037:1FBFA (BOX DRAWINGS LIGHT TOP EDGE)
and L2/25-037:1FBFB (BOX DRAWINGS LIGHT BOTTOM EDGE). In
both proposals, those two characters are specified to be
aligned to top and bottom edges, span the entire edge
(extending to the left and right), and match the thickness
of Box Drawings Light lines. However, the proposal
L2/00-159 had already set precedent for usage of [U+23BA,
U+23BD, U+23B8, U+23B9] (and not the 1÷8 blocks or 1÷4
blocks) in mapping to certain platforms such as The
Heath/Zenith 19 Graphics Character Set and The DEC Special
Graphics Character Set. This contrasts with the usage of
1÷8 blocks [U+2594, U+2581, U+258F, U+2595] and other
related 1÷8 or 7÷8 block characters in the mapping to
PETSCII and Apple II. <span
style="color: rgb(44, 47, 69); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;"><span
class="font"
style="font-family:Inter, -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Segoe UI Emoji", "Segoe UI Symbol", "Apple Color Emoji""><span
class="size" style="font-size:14px">Therefore there
is a discrepancy between the legacy platforms added
in Unicode 3.2 (which use the box drawing lines
23B8, 23B9, 23BA, 23BD) and the legacy platforms
added in Unicode 13.0—17.0 (which use 1÷8 blocks
2594, 2581, 258F, 2595).</span></span></span><br>
</div>
<div><br>
</div>
<div class="gwp597db67c_nh_extra">
<p>Dnia 25 października 2025 10:27 <a class="moz-txt-link-abbreviated" href="mailto:piotrunio-2004@wp.pl">piotrunio-2004@wp.pl</a>
via Unicode <a class="moz-txt-link-rfc2396E" href="mailto:unicode@corp.unicode.org"><unicode@corp.unicode.org></a> napisał(a):<br>
</p>
<blockquote
class="gwp597db67c_nh_quote gwp597db67c_bd-l_base gwp597db67c_bd-c_primary.50 gwp597db67c_pl_2 gwp597db67c_m_0">
<div id="gwp597db67c_gwp60137106">
<div id="gwp597db67c_gwp60137106h">
<div data-color-mode="light"
data-message-body="true"
class="gwp597db67c_gwp60137106b">
<div id="gwp597db67c_gwp60137106_gwp52beef1f">
<div id="gwp597db67c_gwp60137106_gwp52beef1fh">
<div data-message-body="true"
class="gwp597db67c_gwp60137106_gwp52beef1fb">
<div><br>
</div>
<div
class="gwp597db67c_gwp60137106_gwp52beef1f_nh_extra">
<p>Dnia 25 października 2025 08:29 Asmus
Freytag via Unicode
<a class="moz-txt-link-rfc2396E" href="mailto:unicode@corp.unicode.org"><unicode@corp.unicode.org></a>
napisał(a):<br>
</p>
<blockquote
class="gwp597db67c_gwp60137106_gwp52beef1f_nh_quote gwp597db67c_gwp60137106_gwp52beef1f_bd-l_base gwp597db67c_gwp60137106_gwp52beef1f_bd-c_primary.50 gwp597db67c_gwp60137106_gwp52beef1f_pl_2 gwp597db67c_gwp60137106_gwp52beef1f_m_0">
<div
id="gwp597db67c_gwp60137106_gwp52beef1f_gwpcee74020">
<div
id="gwp597db67c_gwp60137106_gwp52beef1f_gwpcee74020h">
<div
class="gwp597db67c_gwp60137106_gwp52beef1f_gwpcee74020b"
data-message-body="true">
<p>Again, the identity of the
Unicode character is giving by
encoding the intended mappings.
If Unicode decides to map the
same character to similar
characters on different
platforms, that is not a
problem, as long as implementers
know that the intent is to use a
platform-specific rendering (and
not assume that there is only
one possible rendering per
character).<br>
</p>
<p>If you feel that the guidance
available to implementers in the
text of the standard or in an
annotation of the nameslist is
not sufficent, then the remedy
would be to ask for the
explanation to be updated. We
are unfortunately locked in as
far as character names are
concerned, but we can add a note
(best in the text of the
standard) that explains that
emulators for some systems will
need an adjusted design so a
sequence or other arrangement of
these characters looks correct.<br>
</p>
</div>
</div>
</div>
</blockquote>
</div>
<div>Indeed the character names cannot be
changed due to stability policies. An
explanation note has been provided for
U+1FB81 that claims "The lines
corresponding to 3 and 5 are not
actually block elements, but can show any
horizontally
repeating pattern", but still implicitly
enforces 1÷8 blocks for top and bottom.
However, this doesn't address other cases
such as the PETSCII C64 variation. And
if 1FB70—1FB81 1FBB5—1FBB8 1FBBC were all
noted to no longer require exact 1÷8
blocks, that would also not remedy the
issue because it would introduce an
inconsistency with the existing 1÷8 or 7÷8
block characters 2581 2589 258F 2594—2595,
which already have established
compatibility precedents that require the
exact fraction, but are also used in the
Unicode 13.0 mapping to PETSCII and Apple
II character sets despite those platforms
using varying thickness (consistent with
light box drawings, except for the 1÷8 top
and bottom blocks in C64, where the 1÷4
top and bottom blocks are made consistent
instead).<br>
</div>
</div>
</div>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
</div>
<div><br>
</div>
</blockquote>
<p><font face="Candara">What is missing is an actual proposal. That
is, not just analysis or exposition, but actual proposed wording
or proposed encoding that would fix the issue.</font></p>
<p><font face="Candara">That would need to be provided as a UTC
document (aka L2 document) submission, with the analysis
appended in a background section. </font></p>
<p><font face="Candara">A./</font></p>
<p><font face="Candara">PS: I am not convinced that
platform-specific mappings (glyphs) are an issue, because the
scenario where these data are reliably transferred *between*
legacy implementations can't have existed then, so it's
questionably why it needs to be perfect today. My assumption
would be that the use case is lossless round trip from (each)
legacy emulator to Unicode and back. Having PETSII / Apple II
specific characters does not improve things, because any data
stream containing those could not be displayed on any other
emulator. This is different from legacy characters mapped to
letters and common text symbols because we have an expectation
that we can share text across devices (or emulators).</font></p>
</body>
</html>