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

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

So, as I can tell, the SEW claims that the issues with the mapping of 
PETSCII/Apple II/HP 264x characters can be resolved by 'using appropriate 
fonts', claims that UTC agreed with this conclusion, and on this basis, the 
SEW announced that they will not be discussing these characters any further. 
This appears to imply that SEW collectively blocks all potential proposals that 
make any of the same disunifications for any of those platforms, no matter how 
much evidence is submitted. In particular, even though the SEW claimed that 
'No evidence of a document that would make a distinction' was provided, 
the SEW will dismiss any actual evidence that follows.   The part of the issue 
that I'm the most certain about is that I don't think the HP 264x 
character can be resolved by 'using appropriate fonts' like the SEW 
claims it can. After all those discussions, I still have not received any 
details regarding how exactly 'using appropriate fonts' would work in 
the case of that HP 264x character. Note that all complex script features such 
as contextual substitutions are completely off topic here, because all the 
character cells are visually independent in a uniform grid. This is two 
visually distinct glyphs mapped to the same Unicode character, leaving no 
standardized way to distinguish the two source platform characters, and 
therefore making it impossible to resolve at the font level. The font can 
almost match, but not actually match the source platform visually, therefore 
making it not actually compatible with the usage of the original platform it 
was intended for.   In the draft of the follow up, which I have submitted but 
the SEW apparently declines to discuss, I have explained that in the diagram of 
 i.imgur.com https://i.imgur.com/vMYk4NN.png , there are examples of 
connections with  𜸫  (0x12) and  𜺴  (0x18) below 𜸢𜸩𜸬 (0x09, 0x10, 0x13). The  𜸫 
 (0x12) character is appropriate for forming an angle with 𜸩 (0x10) as in top 
middle, or 𜸬 (0x13) as in top right, but attempting to continue the diagonal by 
connecting with 𜸢 (0x09) as in top left results in the duplication of bottom 
row of 𜸢 (0x09) and top row of  𜸫  (0x12) therefore forming an implicit short 
vertical segment between the two. The extra pixel in the character  𜺴  (0x18) 
is most likely intended to resolve this discontinuity, forming the connection 
as in the bottom left, with the usage being attested in the large 'N' 
in the example usage of Large Character set as demonstrated in L2/25-037. I 
also confirm the pixel patterns shown in the diagram with the screenshot  
i.imgur.com https://i.imgur.com/pGrUSA7.png .   Even if round trip 
compatibility is not a sufficient argument, there is still the visual 
distinction within the same platform and the distinct connection types that 
those characters make.  Dnia 05 grudnia 2025 08:07 piotrunio-2...@wp.pl via 
Unicode <unicode@corp.unicode.org> napisał(a):   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.