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

[piotrunio-2004@wp.pl]

Dnia 25 października 2025 00:38 Asmus Freytag via Unicode <unicode at corp.unicode.org> napisał(a):  On 10/24/2025 2:58 PM,   piotrunio-2004 at wp.pl  via Unicode wrote:  and not
      subject to font variation.  That's overstating things.  A./  How is that overstating things? When a legacy computing platform defines blocks in terms of fractions, it does so to ensure specific alignment with those fractions, making it part of the fundamental character identity. On the other hand, when a legacy computing platform defines strokes in terms of stem weight and there is known variation across platforms, it is inappropriate to define those characters using exact fractions when those fractions mismatch some of the platforms.   Dnia 25 października 2025 00:44 Asmus Freytag via Unicode <  unicode at corp.unicode.org > napisał(a):  On 10/24/2025 2:54 PM, Nitai Sasson via
      Unicode wrote:  f
      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.  Round tripping plain text to a mix of
        devices is not a goal, just as round tripping plain text Han
        characters to a mix of regional variants is not a goal.  You (Piotr) need to demonstrate that for a
        single display, on a single device or emulator for a single
        device, you cannot get the correct appearance by systematically
        using a device appropriate font.  If a device supports "shifted" modes, then a
        device appropriate font may change based on the shift status.  Only when that accommodation fails to
        produce the correct appearance is there a case for further
        disunification.  The diagonal connector issue satisfies this
        requirement, but as far as I have been able to understand, the
        block characters do not.  A./    In case of PETSCII and Apple II characters, this is an instance of source characters having an incompatible character identity from their mapped Unicode characters. Therefore, there is a character identity conflict between the legacy platform and the Unicode characters they are mapped to.  Whereas in case of HP 264x characters, two source characters having an incompatible character identity from each other are mapped to the same Unicode character. Therefore, there is a character identity conflict between the two characters.   The required evidence to support a request for disunification therefore  always consists of a document (screenshot) (usually other than a  character set table) that shows that the two characters are distinct in  their source environment and that that distinction matters (for example,  that it can't be determined mechanically by context).   From the original document (section 1, page 1), it looks like that  there are two characters that are distinct in the source, but have been  mapped to the same Unicode character 1CE2B. I can certainly sympathize  with the view that unifying these based on their close visual similarity  was, what we used to call a case of "arms-length" unification.   As I have explained in  corp.unicode.org Odp: Re: Unicode fundamental character identity , This is what it looks like on a screenshot:  i.imgur.com https://i.imgur.com/obGQ4Ie.png  . The two different characters and their different types of connections are demonstrated. Furthermore, since all character tiles are visually independent, and both characters may be used as isolated character cells, no contextual mechanism can possibly apply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20251025/80206b21/attachment.htm>