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

Sat, 31 Jan 2026 07:14:32 -0800 

The SEW did not read the updated evidence in the follow up draft yet, but 
announced that "I tried in December and I tried again this week and I got 
one person willing to discuss whether a variant selector would be something 
appropriate to consider.".   However, using a variation selector for the HP 
264x character would significantly overcomplicate implementations which will no 
longer be able to use a simple mapping from 6-bit HP 264x tiles to Unicode code 
points, and that encoding it as an atomic character is therefore more 
reasonable in terms of cost to benefit ratio.   The SEW subsequently announced 
"It was made clear to me several times that not a single person is willing 
to encode a new character for glyph variants/presentation forms." and 
"There is a chance a VS would be considered, but as I said it was one 
person and I allocated a few minutes in the next meeting to see if anyone else 
would be supportive of that solution. If VS wouldn’t work, then there is no 
need to be reopening this topic.".   However, the problem is that SEW was 
asking its members if they are willing to encode a new character for glyph 
variants/presentation forms, when the updated evidence in the follow up draft 
shows that the proposed HP 264x character has a  unique structural function and 
therefore has a distinct identity. That character is not a glyph variant, let 
alone a presentation form. The concept of 'glyph variant' only occurs 
when the distinction is a style variation (whereas in HP 264x they coexist 
within the same character set in the same text style, making it a plain text 
distinction) whereas the concept of 'presentation forms' only applies 
to shaping scripts (initial, medial, final, isolated, composed, contextual, 
etc.), which the Large Character Set characters have nothing to do with. In 
particular, the character identity of any character intended to connect to 
surrounding characters is defined by the types of connections that the 
character forms, which are shown to be distinct, and the visual distinction is 
shown to be a consequence of the distinct connection types. Therefore the 
question shouldn't be "Are you willing to encode a new character  𜺴  
for glyph variants/presentation forms of  𜸫 ?", but "Are you willing to 
encode a new character  𜺴  for the HP 264x character that forms a continuous 
diagonal connection above, visually and structurally distinct from the corner 
connections formed by  𜸫, and with both coexisting in the same text document  
as shown in  i.imgur.com https://i.imgur.com/pGrUSA7.png , and completing the 
proper mapping to HP 264x Large Character Set characters? ".   Dnia 24 
grudnia 2025 00:35 [email protected] via Unicode 
<[email protected]> napisał(a):  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 [email protected] via Unicode 
<[email protected]> napisał(a):   Dnia 05 grudnia 2025 01:23 Asmus 
Freytag via Unicode <[email protected]> napisał(a):  On 12/4/2025 
2:37 PM, [email protected] 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.

Reply via email to