<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 10/29/2022 1:18 PM, Sławomir Osipiuk
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1667073947992.3769056767.4121947635@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <span class="viv-signature"></span>On Saturday, 29 October 2022,
      15:43:03 (-04:00), Asmus Freytag via Unicode wrote:<br>
      <br>
      <blockquote style="padding-left:1ex;border-left-color:rgb(0, 0,
255);border-left-style:solid;border-left-width:2px;margin-left:0px;margin-bottom:0.8ex;margin-right:0px;margin-top:0px;">
        <div class="moz-cite-prefix">According to <a
            class="moz-txt-link-freetext"
            href="https://en.wikipedia.org/wiki/TI_calculator_character_sets"
            moz-do-not-send="true">https://en.wikipedia.org/wiki/TI_calculator_character_sets</a>
          the "negation" is mapped to U+207B SUPERSCRIPT MINUS in TI
          Character sets. Unless that information is definitely
          incorrect, this should be the end of discussion.</div>
        <div class="moz-cite-prefix"><br>
        </div>
        <div class="moz-cite-prefix">A./</div>
      </blockquote>
      <div> </div>
      <div>I tried to look through the sources for that page but found
        no definitive mapping. The Unicode values seem to have simply
        been matched by sight by the editor. The sources contain only
        bitmaps of the characters and their TI-internal byte values.
        Just another reminder that Wikipedia is not always reliable.</div>
      <span class="viv-signature-below"></span>
    </blockquote>
    <p><font face="Candara">The Wikipedia article does show a mapping.
        And, no matter its origin, that mapping appears uncontested. (I
        haven't looked through the page history, but that's where you
        would find any disagreement on the issue; unless you can point
        us to something in there, I'll assume it's uncontested; let me
        know what you find).</font></p>
    <p><font face="Candara">Because it's a mapping and out there,
        there's now a published choice for how to represent that
        character in Unicode. That fact alone changes the question from
        a completely open one to one where there's a de-facto "proposed
        solution". If you (or anyone) disagrees, you would have to
        demonstrate why that choice is incorrect or insufficient.</font></p>
    <p><font face="Candara">And, "matching by sight" isn't necessarily
        an incorrect approach. Unicode distinguishes between the
        identity of a character and the thing that it denotes in a
        certain context --- with very deliberate exceptions.</font></p>
    <p><font face="Candara">For '.', for example, the precedent is very
        strong: The identity is the "period" whether used as a full stop
        or decimal point, or delimiter in internet addresses or
        abbreviation marker.  For ':' we don't code a different
        character for the use of abbreviation marker in Swedish, and so
        on.<br>
      </font></p>
    <p><font face="Candara">For letters, on the other hand, membership
        in a certain script, or having a particular case mapping can
        contribute to the defining characteristics of a character's
        identity, leading to disunification of otherwise identical
        shapes.</font></p>
    <p><font face="Candara">For dashes, Unicode considers that
        differences length, and position relative to baseline or
        centerline are charateristics that make two dashes distinct
        symbols. However, that means that when two dashes have identical
        appearance, they should not be disunified based simply on how
        they are used. (The issue is a bit more complex than that,
        because ASCII unifies two of them into 002D, but that's a
        historical one-off, not a precedent).</font></p>
    <p><font face="Candara">So, if you disagree with this mapping,
        you'll have to demonstrate that there's a consistent visual
        difference to the "actual" character, such that it would render
        SUPERSCRIPT MINUS distinct from the unary negation. Otherwise,
        the conclusion stands that there is one known convention (TI
        character set) that uses SUPERSCRIPT MINUS to indicate unary
        negation.</font></p>
    <p><font face="Candara">A./</font></p>
    <p><font face="Candara">PS: interestingly enough, one of the sources
        cited for the Wikipedia article actually has a mapping to U+203E
        (spacing overline). You now have two choices of "de-facto"
        mappings; however, I think we can agree that U+203E seems a much
        poorer match for the glyph given for negation that U+207B; the
        former is at caps height, the latter between centerline and
        caps. The dot matrix glyph image has the negation 1 pixel above
        center.  The resolution severely limits the available positions;
        like the position of SUPERSCRIPT MINUS in Cambria math, the TI
        negation sits on just between the centerline of superscripted
        digits and their (raised) baseline. I think whoever came up with
        that mapping did a better job than whoever mapped this to
        U+203E.<br>
      </font></p>
  </body>
</html>