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

[piotrunio-2004@wp.pl]

Dnia 25 października 2025 00:05 Nitai Sasson via Unicode <unicode at corp.unicode.org> napisał(a):     On Friday, 24 October 2025 at 23:57, piotrunio-2004 at wp.pl via Unicode <unicode at 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.org at sl.neatnit.net > napisał(a):   piotrunio-2004 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20251025/b2368627/attachment-0001.htm>