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

[piotrunio-2004@wp.pl]

Dnia 05 grudnia 2025 01:23 Asmus Freytag via Unicode <unicode at corp.unicode.org> napisał(a):  On 12/4/2025 2:37 PM, piotrunio-2004 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20251205/c5eba2ec/attachment.htm>