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

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

Dnia 25 października 2025 00:38 Asmus Freytag via Unicode 
<unicode@corp.unicode.org> napisał(a):  On 10/24/2025 2:58 PM,   
piotrunio-2...@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@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.