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

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

Dnia 25 października 2025 00:05 Nitai Sasson via Unicode 
<unicode@corp.unicode.org> napisał(a):     On Friday, 24 October 2025 at 
23:57, piotrunio-2...@wp.pl via Unicode <unicode@corp.unicode.org> wrote: 
 How is it a “proper explanation,” to make a claim that the issues 'can be 
solved by using appropriate fonts' when the proposal already makes it clear 
that they can't?   If my understanding is correct, the meaning is: if you 
use a font that makes those Unicode characters look like they did on their 
original platform, there is no issue. But a given font can only emulate one 
platform at a time. You're not going to get a C64 and PET/VIC-20 
frankenstein of a document. Take your pick: do you want it to look like C64, or 
do you want it to look like PET/VIC-20? Choose your font accordingly.   If 
fonts  still  don't solve this the way I just described, you have not yet 
given an example of this.   There's no doubt that the PET/VIC-20 font and 
C64 font are two different fonts.  But for example, when attempting to encode 
PETSCII 0x45 into Unicode. The intended mapping is to U+1FB76 (HORIZONTAL ONE 
EIGHTH BLOCK-2). This implies that the character includes a block that 
horizontally spans the character cell width, and vertically spans from 1÷8 to 
2÷8 (between top and bottom) of the character cell height; in other words, it 
consists of the 1×8 bitmap [0,1,0,0,0,0,0,0,] stretched to the character cell. 
This definition matches the PET/VIC-20 version of the character, but not the 
C64 (where it vertically spans from 1÷8 to 3÷8 instead). The C64 version of the 
character contradicts the Unicode definition of U+1FB76, therefore making it 
impossible to use U+1FB76 to represent that character.    As for the HP 264x 
'2' vs '8', I will admit I have never heard of this before, but 
it seems to me that the '8' is only ever used in the diagonal of the 
capital N, and the '2' seems to connect identically on the right and 
even better on the top. I am not sure why the '8' exists at all, but in 
any case, you haven't shown instance where the '2' can't fill 
its place.   - Nitai Sasson    (for all intents and purposes, just some guy)    
In that context, where the '8' is connected below the ')', the 
extra pixel at the top of the '8' continues the diagonal at the bottom 
of the ')'. If the '2' fills its place, then the bottom row of 
')' and top row of '2' are the same, resulting in a small 
discontinuity, which the alternative '8' character is supposed to 
resolve. And both are different characters in the same encoding.    Dnia 25 
października 2025 00:13 Nitai Sasson <  unicode....@sl.neatnit.net > 
napisał(a):   piotrunio-2...@wp.pl :  The characters  1FB70—1FB81 1FBB5—1FBB8 
1FBBC ,
 as specified in Unicode 13.0—17.0, are defined with 1÷8 blocks.   No, 
they're not. That might be in their name, but fonts may render them 
differently. Notice the following section of this file:   www.unicode.org 
https://www.unicode.org/charts/PDF/U1FB00.pdf  Fonts  The shapes of the 
reference glyphs used in these code charts are not prescriptive. Considerable 
variation is to be  expected in actual fonts.     There are many instances 
where the name of a codepoint doesn't tell the full story. This is one of 
them. Fonts can and should render this as something different than 1/8 blocks 
if their design purpose calls for it.   Nitai Sasson   When a character name 
doesn't tell the full story, it's because the name is not specific 
enough. However, in case of block elements that are specifically defined by 
fractions, the definition is already specific enough.