Re: Odp: RE: What to do if a legacy compatibility character is defective?

[piotrunio-2...@wp.pl via Unicode]

Dnia 05 grudnia 2025 01:23 Asmus Freytag via Unicode 
<unicode@corp.unicode.org> napisał(a):  On 12/4/2025 2:37 PM, 
piotrunio-2...@wp.pl via Unicode wrote:  However, the SEW announced that they 
will not be discussing these  characters any further, so how could any follow 
up of the proposal  possibly get incorporated into Unicode?   Nothing can force 
the SEW to accept any particular proposal. However,  unless there's a 
document actually submitted, there's nothing that will  happen at all, no 
matter what.  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.   If it 
were up to me, I would focus on suggesting specific language for  the standard 
or the nameslist rather than proposing new characters. Such  feedback may be 
reviewed by other working groups, not solely SEW.   A./  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.