<div><br></div><div class="nh_extra"><p>Dnia 05 grudnia 2025 01:23 Asmus Freytag via Unicode <unicode@corp.unicode.org> napisał(a):<br></p><blockquote class="nh_quote bd-l_base bd-c_primary.50 pl_2 m_0"><div id="gwp0b6f3739"><div>On 12/4/2025 2:37 PM, piotrunio-2004@wp.pl via Unicode wrote:<br></div><blockquote><div>However, the SEW announced that they will not be discussing these<br></div><div>characters any further, so how could any follow up of the proposal<br></div><div>possibly get incorporated into Unicode?<br></div></blockquote><div><br></div><div>Nothing can force the SEW to accept any particular proposal. However,<br></div><div>unless there's a document actually submitted, there's nothing that will<br></div><div>happen at all, no matter what.<br></div></div></blockquote></div><div id="gwp9c7ecea3"><div id="gwp9c7ecea3h"><div data-message-body="true" class="gwp9c7ecea3b" data-color-mode="light"><div>I have already submitted the draft of the follow up. However, I don't intend to force the characters to be accepted, but instead I requested for the SEW to be made aware of the information in the follow up, so that I can continue receiving more detailed feedback that I can then use to further clarify the issue or explore potential alternative solutions.<br></div><div><br></div></div></div></div><div class="nh_extra"><blockquote class="nh_quote bd-l_base bd-c_primary.50 pl_2 m_0"><div id="gwp0b6f3739"><div>If it were up to me, I would focus on suggesting specific language for<br></div><div>the standard or the nameslist rather than proposing new characters. Such<br></div><div>feedback may be reviewed by other working groups, not solely SEW.<br></div><div><br></div><div>A./<br></div></div></blockquote></div><div id="gwp9c7ecea3"><div id="gwp9c7ecea3h"><div data-color-mode="light" class="gwp9c7ecea3b" data-message-body="true"><div><div id="gwp9c7ecea3h"><div data-color-mode="light" class="gwp9c7ecea3b" data-message-body="true"><div>The issue for the 1÷8 blocks (in Apple II, PETSCII, etc.) is that their encoding policy is not consistent with the previously encoded box drawing lines (in Heath/Zenith 19, DEC Special Graphics, etc.), therefore making it inappropriate to use 1÷8 blocks in the encoding of those characters for those platforms. The issue is even worse for the C64/C128 PETSCII mapping, which is not even consistent within the same platform where the characters which L2/19-025 mapped to 1÷8 blocks 1FB7C—1FBFF (🭼🭽🭾🭿) are aligned with top and bottom 1÷4 blocks (🮂▂) but are misaligned with top and bottom 1÷8 blocks (▔▁), which makes it a misuse of the 1÷8 block character identity (in the context of that platform, top and bottom 1÷4 blocks have same thickness as box drawings, which better matches the usage of 23BA 23BD ⎺⎽ instead). Whereas the issue for the HP 264x character is that the character can be used independently from the other character that Unicode unified it with and that it forms a distinct connection type. As I can tell, those issues are baked into the existing Unicode 13.0—17.0 mappings of those platforms, so I don't see how 'specific language for the standard or the nameslist' could possibly address those issues.<br></div></div><div><br></div></div></div></div></div></div>