<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/6/19 5:30 PM, Billy O'Neal (VC
      LIBS) wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:MW2PR2101MB109809F557350452323EA939CB790@MW2PR2101MB1098.namprd21.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:"Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"\@Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
      <div class="WordSection1">
        <p class="MsoNormal">Corentin’s PR says “if char (the execution
          encoding) can always represent µ for your implementation, use
          that. Otherwise use u.” Which means on my implementation where
          char can’t always represent such a thing as that is locale
          dependent. we will statically use u (and µ for wchar_t); but
          an implementation that assumes char is UTF-8 could use µ.<br>
          <br>
        </p>
        <p class="MsoNormal">The LWG issue’s PR says “if the stream can
          detect that it is targeting a console or codecvt facet that
          don’t support µ, an implementation  may use u, otherwise they
          use µ”. But streams have no means of doing that detection.
          (And the answer can even change if someone changes the
          streambuf)</p>
      </div>
    </blockquote>
    <p>That isn't what it (is intended to) say, nor how I read it.  It
      states that the suffix is determined by the execution character
      set (the character set used for string literals and known at
      compile time); that is in the first sentence.  The second sentence
      acknowledges that if the native character set (the run-time locale
      dependent character set) lacks representation for the character,
      then all bets are off with regard to how the character is actually
      displayed (or converted by a codecvt facet).</p>
    <p>The intent of the wording was to allow Microsoft to use "µs" when
      the compiler is invoked with /execution-charset:utf-8 and to use
      "us" otherwise.<br>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:MW2PR2101MB109809F557350452323EA939CB790@MW2PR2101MB1098.namprd21.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Billy3</p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <hr style="display:inline-block;width:98%" tabindex="-1">
      <div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
          color="#000000" face="Calibri, sans-serif"><b>From:</b> Tom
          Honermann <a class="moz-txt-link-rfc2396E" href="mailto:tom@honermann.net">&lt;tom@honermann.net&gt;</a><br>
          <b>Sent:</b> Wednesday, November 6, 2019 5:14:18 PM<br>
          <b>To:</b> Billy O'Neal (VC LIBS) <a class="moz-txt-link-rfc2396E" href="mailto:bion@microsoft.com">&lt;bion@microsoft.com&gt;</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:lib@lists.isocpp.org">lib@lists.isocpp.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:lib@lists.isocpp.org">&lt;lib@lists.isocpp.org&gt;</a>; Corentin
          <a class="moz-txt-link-rfc2396E" href="mailto:corentin.jabot@gmail.com">&lt;corentin.jabot@gmail.com&gt;</a><br>
          <b>Cc:</b> C++ Library Evolution Working Group
          <a class="moz-txt-link-rfc2396E" href="mailto:lib-ext@lists.isocpp.org">&lt;lib-ext@lists.isocpp.org&gt;</a>; <a class="moz-txt-link-abbreviated" href="mailto:unicode@isocpp.open-std.org">unicode@isocpp.open-std.org</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:unicode@open-std.org">&lt;unicode@open-std.org&gt;</a><br>
          <b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
          [isocpp-lib-ext] [time.duration.io] : Is stream insertion
          behavior locale dependent when Period::type is micro?</font>
        <div> </div>
      </div>
      <div style="background-color:#FFFFFF">
        <div class="x_moz-cite-prefix">On 11/6/19 4:30 PM, Billy O'Neal
          (VC LIBS) wrote:<br>
        </div>
        <blockquote type="cite">
          <meta name="Generator" content="Microsoft Word 15 (filtered
            medium)">
          <style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:"Yu Gothic"}
@font-face
        {font-family:Calibri}
@font-face
        {}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
        {color:blue;
        text-decoration:underline}
.x_MsoChpDefault
        {}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
        {}
-->
</style>
          <div class="x_WordSection1">
            <p class="x_MsoNormal" style="margin-bottom:12.0pt">&gt;
              Please read the wording again. Note that it says that, if
              those conditions are true, then the result is
              unspecified. </p>
            <p class="x_MsoNormal">If “the wording” means the P/R of <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639648909&amp;sdata=7GBDeNaCU2%2B64mxLltJkFfdRuDybqgmOYQA4RPFWHRI%3D&amp;reserved=0"
                originalsrc="https://cplusplus.github.io/LWG/issue3314"
shash="ACAmmLrmVBUzxch4Hx/1p4Hk2FYnvOj+FakMK/NyDkUc4yxG/Eq7fz8khBbLdYdXo6r+PErzKJskYtqBa1f2zpYiQxIm4MI5CViELNwdbVPVif7pnzIGgJvgvBaH/8PtT84yxWmxt7u4pwoe0VeGOCRdRs14yE8ZX4o4dCtLPc8="
                moz-do-not-send="true">
                https://cplusplus.github.io/LWG/issue3314</a>, the
              wording there implies that we must make some effort to
              determine that the condition is true, which in practice we
              cannot do because the interface between streams and
              streambufs is public.</p>
          </div>
        </blockquote>
        <p>Yes, that is the wording I meant.  The intent is to ensure
          the implementation does *not* have to put forth such effort. 
          I don't understand where such an implication is coming from,
          but that wording has confused at least three experienced
          wordsmiths, so I acknowledge there is an issue, but I don't
          understand what it is.<br>
        </p>
        <p>I think it is important to say something here.  Otherwise,
          one could claim that the terminal failing to display
          <tt>"μs"</tt> because it is configured for an incompatible
          encoding is non-conforming.  Well, to the extent that the
          standard addresses such devices.<br>
        </p>
        <p>Tom.<br>
        </p>
        <blockquote type="cite">
          <div class="x_WordSection1">
            <p class="x_MsoNormal"> </p>
            <p class="x_MsoNormal">Corentin’s P/R below seems to not
              have this concern.</p>
            <p class="x_MsoNormal"> </p>
            <p class="x_MsoNormal">Billy3</p>
            <p class="x_MsoNormal"> </p>
          </div>
          <hr tabindex="-1" style="display:inline-block; width:98%">
          <div id="x_divRplyFwdMsg" dir="ltr"><font
              style="font-size:11pt" color="#000000" face="Calibri,
              sans-serif"><b>From:</b> Lib
              <a class="x_moz-txt-link-rfc2396E"
                href="mailto:lib-bounces@lists.isocpp.org"
                moz-do-not-send="true">&lt;lib-bounces@lists.isocpp.org&gt;</a>
              on behalf of Tom Honermann via Lib
              <a class="x_moz-txt-link-rfc2396E"
                href="mailto:lib@lists.isocpp.org"
                moz-do-not-send="true">&lt;lib@lists.isocpp.org&gt;</a><br>
              <b>Sent:</b> Wednesday, November 6, 2019 1:12:48 PM<br>
              <b>To:</b> Corentin <a class="x_moz-txt-link-rfc2396E"
                href="mailto:corentin.jabot@gmail.com"
                moz-do-not-send="true">
                &lt;corentin.jabot@gmail.com&gt;</a><br>
              <b>Cc:</b> Tom Honermann <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:tom@honermann.net" moz-do-not-send="true">
                &lt;tom@honermann.net&gt;</a>; C++ Library Evolution
              Working Group <a class="x_moz-txt-link-rfc2396E"
                href="mailto:lib-ext@lists.isocpp.org"
                moz-do-not-send="true">
                &lt;lib-ext@lists.isocpp.org&gt;</a>; Library Working
              Group <a class="x_moz-txt-link-rfc2396E"
                href="mailto:lib@lists.isocpp.org"
                moz-do-not-send="true">
                &lt;lib@lists.isocpp.org&gt;</a>; <a
                class="x_moz-txt-link-abbreviated"
                href="mailto:unicode@isocpp.open-std.org"
                moz-do-not-send="true">
                unicode@isocpp.open-std.org</a> <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:unicode@open-std.org"
                moz-do-not-send="true">
                &lt;unicode@open-std.org&gt;</a><br>
              <b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
              [isocpp-lib-ext] [time.duration.io] : Is stream insertion
              behavior locale dependent when Period::type is micro?</font>
            <div> </div>
          </div>
          <div dir="auto">The intent of the wording is to say that
            implementors do *not* need to be aware of terminals or
            codecvt facets. Without this, the wording could be read that
            implementations must implement magic to make the character
            display correctly. 
            <div><br>
            </div>
            <div>Please read the wording again. Note that it says that,
              if those conditions are true, then the result is
              unspecified. <br>
              <br>
              <div id="x_x_AppleMailSignature" dir="ltr">Tom.</div>
              <div dir="ltr"><br>
                On Nov 6, 2019, at 12:07 PM, Corentin &lt;<a
                  href="mailto:corentin.jabot@gmail.com"
                  moz-do-not-send="true">corentin.jabot@gmail.com</a>&gt;
                wrote:<br>
                <br>
              </div>
              <blockquote type="cite">
                <div dir="ltr">
                  <div dir="ltr">Then I would just say associated
                    execution encoding with charT
                    <div><br>
                    </div>
                    <div>Extremely uncomfortable with involving stream,
                      console or anything else not known at compile
                      time  </div>
                  </div>
                  <br>
                  <div class="x_x_gmail_quote">
                    <div dir="ltr" class="x_x_gmail_attr">On Wed, 6 Nov
                      2019 at 04:51, Tom Honermann &lt;<a
                        href="mailto:tom@honermann.net"
                        moz-do-not-send="true">tom@honermann.net</a>&gt;
                      wrote:<br>
                    </div>
                    <blockquote class="x_x_gmail_quote"
                      style="margin:0px 0px 0px 0.8ex; border-left:1px
                      solid rgb(204,204,204); padding-left:1ex">
                      <div bgcolor="#FFFFFF">On 11/6/19 8:30 AM, Howard
                        Hinnant wrote:<br>
                        <blockquote type="cite">
                          <pre>You can comment the LWG issue (if you want) by emailing said comment to <a href="mailto:lwgchair@gmail.com" target="_blank" moz-do-not-send="true">lwgchair@gmail.com</a>, specifying which issue you wish to comment and supplying the comment.

Howard

On Nov 5, 2019, at 10:32 PM, Corentin via Lib-Ext <a href="mailto:lib-ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">&lt;lib-ext@lists.isocpp.org&gt;</a> wrote:
</pre>
                          <blockquote type="cite">
                            <pre>Not sure how to do that proceduraly but here is some alternative wording.
The "runtime" locale-tied encoding is *assumed to be* a super set of the execution encoding - to the extent the standard doesn't distinguish between the two


If Period::type is micro, but the &lt;ins&gt;abstract&lt;/ins&gt; character &lt;ins&gt;µ , which has the universal character name &lt;/ins&gt; U+00B5 cannot be represented in the &lt;ins&gt;execution&lt;/ins&gt; encoding &lt;del&gt;used for&lt;/del&gt;&lt;ins&gt; associated with the character type &lt;/ins&gt; charT, the unit suffix "us" is used instead of "µs".</pre>
                          </blockquote>
                        </blockquote>
                        <br>
                        <div>Howard and I discussed the wording I
                          proposed today and we're now on the same page
                          with regard to the intent.<br>
                        </div>
                        <div><br>
                        </div>
                        <div>With regard to Corentin's suggested wording
                          above, "abstract character" and "execution
                          encoding" are not current terms in the
                          standard (well, the former is inherited from
                          our reference to the Unicode standard but is
                          otherwise unused at present). 
                          <a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp1859r0&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639658899&amp;sdata=ZRSB0GKnWzhgzQArFZMtAvhJ912CIBttXg1lXijUgjQ%3D&amp;reserved=0"
                            originalsrc="http://wg21.link/p1859r0"
shash="HQ+ywW22oeFjzWDtjb46SYhadyBj1ftiw5fSaun31F45tw3zo8HNeropCQj6xozoy73A/flmu5Ub8d22z0jiRp0RbOWEve22TGrIzAUbO6BGfe48BmKpRQEqHu4eED5Ohc5IyUeT+EbEqo4xWSVQs5uEXuI7YDER/x9SS1gKDlY="
                            target="_blank" moz-do-not-send="true">
                            P1859R0</a> does intend to standardize new
                          terminology, but we don't yet have consensus
                          for what the new terms should be named.  I
                          think we should avoid using candidate names
                          until we have such consensus.<br>
                        </div>
                        <div><br>
                        </div>
                        <div>Tom.<br>
                        </div>
                        <div><br>
                        </div>
                        <blockquote type="cite">
                          <blockquote type="cite">
                            <blockquote type="cite">
                              <pre>On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <a href="mailto:lib-ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">&lt;lib-ext@lists.isocpp.org&gt;</a> wrote:
A new LWG issue was filed for this question today:
- <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639668895&amp;sdata=uC3YRt9nkh4RHBan05r7vgp80RqZ9MTT3OS9H8MEDFY%3D&amp;reserved=0" originalsrc="https://cplusplus.github.io/LWG/issue3314" shash="EawDuLo4/O8KLUUoh7S+Xw6OEP632FV6Oo4Nkhk03gnVZekcGPZ5/fXIKVh6/FKRwvZhd3KVAdYccFhI2s0w5HoSUq3muav4mhKeIxxRU2jXvnE/ZFIP/XNUULfwByxmu1lLCOKz60xF+DUsskmDpO/+kFH51SICNnckQ3/Nga0=" target="_blank" moz-do-not-send="true">https://cplusplus.github.io/LWG/issue3314</a>

This issue concerns the ostream inserters added for std::chrono::duration in C++20 and what the intended behavior is for a duration when period::type is micro.

[<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftime.duration.io&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639668895&amp;sdata=KL8P5jLXGV%2FXWF1%2F11L8IiiCHY1Nf3IRL%2Fhnu%2BVtMcM%3D&amp;reserved=0" originalsrc="http://time.duration.io" shash="ep4okPw0uBuj4Wt3xpDWHD408MEVVHA4jpxSJubM7gitMUsJY6oyjEd/VPArNgtp0JK5FOJ6BsYzOkDPlKlBNCYlxYNwApkINgwbU/AhpRnd1GFvhL+pd3DfblMFi5iz2muujbOZZaQ+dkRFsTFDosmYOPT5+kMKCJm6IwINcsM=" target="_blank" moz-do-not-send="true">time.duration.io</a>]p4 states:


</pre>
                              <blockquote type="cite">
                                <pre>If Period​::​type is micro, but the character U+00B5 cannot be represented in the encoding used for charT,           the unit suffix "us" is used instead of "μs".

</pre>
                              </blockquote>
                              <pre>The question is with regard to which one of the encodings used for charT is referred to here; the compile-time execution character set or the run-time locale dependent native character set?

The proposed resolution specifies that the compile-time execution character set is the intended one.  My expectation is that this aligns with existing implementations, but I haven't checked.

Tom.

</pre>
                            </blockquote>
                            <pre>_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639678891&amp;sdata=q8STNMI8xDAbgpdthf8VgIbgNvzADEDmnmLJRYzQ8uc%3D&amp;reserved=0" originalsrc="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" shash="G0e90AcVchT2AsZ2yeI+3za+1DHKd6XCdZJMmz6UocZnguolifbUpsUv1Kjym0E1jV4UWBxEpclqfaPsfGHtYn6vhOd7fWj9Rpg+7OhkE2sXZOYzkNQ1xyj2IHcOsFWk99JiEZdfcjyIXe4GYICt69aWvTqdxy5qy4NgMHyB04c=" target="_blank" moz-do-not-send="true">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13309.php&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639688887&amp;sdata=ZtRjYdN7d%2FeiuJezp8vyxOOtsOOZc0%2BqDXGoZq2tqCI%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/lib-ext/2019/11/13309.php" shash="wkcjgzOizsTtDXL6PB/SG0+NnSqrXI9jmC9PaFmX+jZQPIECPMatXG2z/Y9c9ZSedftocAapUh6RZ27tNkplFraeIGPAhcp4QxBVMP+XXxXlX41pY+vmQpHQ0az4K0yhiJ5YGzzlCb/YQ6TOwdHa98XsQ8OOgrsI+Y8m9L0u0iY=" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/lib-ext/2019/11/13309.php</a>
_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639688887&amp;sdata=o37Ay5VWpZ7hqbglGhSpsl0DbpKNm%2BP4YckKbNMvgCs%3D&amp;reserved=0" originalsrc="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" shash="XyTAcT2+Iq1V3p01Lwp9jgt5twMSMShMpnm9yNiWE4Cdif3mUlfoY56hhDeYc0cKHdx/ycBZm3ADVwuONWdhPA52WH39gGuCCRJ+3s3Ck8BHINUwCbl5Sr1ELHsitzVEXSRJ8nj2E3fVN7wuBIeWWzkEyunPkL8LIrbpLGCcEQw=" target="_blank" moz-do-not-send="true">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13325.php&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639698882&amp;sdata=DWLr80dJM2Zqg5Ad44m%2B%2BvQLN8sO%2B37DyJRnX5iDIas%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/lib-ext/2019/11/13325.php" shash="qJMumsXyxxtuv3xGSZ1XhIQWiB8pW4BAl2MM3w34+2xSUEyE3ycCgis2WjVa4f9J/xUygwRI7BraUCC6QgXpgBQ3DO3dL/AUkkorF6xoro1MtLKjkutgSoI9Osv0FF7SYzoQecYY2eCme9/82x7UhmbLIcDik+hRB4/mo2pp8Zk=" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/lib-ext/2019/11/13325.php</a>
</pre>
                          </blockquote>
                          <br>
                          <fieldset></fieldset>
                          <pre>_______________________________________________
SG16 Unicode mailing list
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank" moz-do-not-send="true">Unicode@isocpp.open-std.org</a>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Funicode&amp;data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639708883&amp;sdata=RQAtQ3ROTPGMOSZTLZjXw%2BdgQWD4FYdftkbYd4L4c24%3D&amp;reserved=0" originalsrc="http://www.open-std.org/mailman/listinfo/unicode" shash="Q0vqD89HyXW8tDrqwz6VwA11ctzwceM0lXHsDrNh4KzlZOAaxEQJh+CdHCc/GUXLScRvNshI66/jwy5qwMJEpJu+oxmyKqmkAyOo6oQP78GcwUZMXHH733zU5iKvbz+u4qnTqXEfjK9bkb+kRVfvqnqFmDY+txINLe7oHQYLO3A=" target="_blank" moz-do-not-send="true">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
                        </blockquote>
                        <p><br>
                        </p>
                      </div>
                    </blockquote>
                  </div>
                </div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <p><br>
        </p>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>