<div dir="auto">To add some data point, Qt, gtk, skia, SDL, Cocoa and others expect utf-8 encoded text.<div dir="auto"><br></div><div dir="auto">On some platform conversation are required and there may be several conversions depending on what the encoding of the font used to render is.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I would caution against designing an API intended to communicate with human beings that would make it painfully difficult to do so.</div><div dir="auto"><br></div><div dir="auto">A more interesting question is whether the API should expect a higher level text object rather than a sequence of code units. Afaik fonts operate on code point sequences</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 14, 2019, 6:10 AM Tom Honermann &lt;<a href="mailto:tom@honermann.net" target="_blank" rel="noreferrer">tom@honermann.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>SG16 discussed the text related aspects of P0267R9 at our
      teleconference held June26th, 2019.  Meeting notes are available
      at:<br>
      - <a href="https://github.com/sg16-unicode/sg16-meetings#june-26th-2019" rel="noreferrer noreferrer" target="_blank">https://github.com/sg16-unicode/sg16-meetings#june-26th-2019</a></p>
    <p>We did not conduct any polls during the teleconference, but will
      do so when we discuss this paper in SG16 at Cologne.</p>
    <p>The relevant portions of the meeting notes are copied below for
      convenience.</p>
    <ul>
      <li><a href="https://wg21.link/p0267r9" rel="nofollow noreferrer noreferrer" target="_blank">P0267R9 - A
          Proposal to Add 2D Graphics Rendering and Display to C++</a>:
        <ul>
          <li>Tom, unsurprisingly, stated that the interface should use
            <code>std:u8string</code> since it requires UTF-8 encoded
            text.</li>
          <li>Michael agreed and expressed dislike for the asumption of
            UTF-8 in a <code>std::string</code> object.</li>
          <li>Zach stated that the interfaces should be <code>std::string_view</code>
            and execution encoding.</li>
          <li>Steve pondered whether all current graphical display
            systems are Unicode.</li>
          <li>Tom stated that the X window system is locale based.</li>
          <li>Zach suggested it would be least surprising to programmers
            to use execution encoding. That way they can just
            pass regular strings.</li>
          <li>Peter stated that, On UNIX systems, UTF-8 tends to be the
            default, so things will work as is, but Windows
            would be problematic.</li>
          <li>Zach observed that, without standard library support,
            converting text from execution encoding to UTF-8 is hard.</li>
          <li>Peter suggested leaving it to the UI libraries to figure
            it out.</li>
          <li>Zach responded that this is a UI library, so we need to
            figure it out.</li>
          <li>Michael pondered whether we should add overloads for <code>char</code>,
            <code>wchar_t</code>, <code>char8_t</code>, <code>char16_t</code>,
            and <code>char32_t</code>.</li>
          <li>Zach suggested that we only need <code>char</code> and <code>char8_t</code>.</li>
          <li>Hubert observed that the standard library is designed
            around locales.</li>
          <li>Tom asked Hubert to clarify, are you thinking these
            interfaces should take a locale object?</li>
          <li>Hubert responded that, if you have strings that you don&#39;t
            know the encoding for, then yes.</li>
          <li>JeanHeyd expressed a preference for just using <code>std::u8string</code>
            to avoid locale dependencies.</li>
          <li>Mark agreed that, perhaps, just <code>char8_t</code> is
            enough.</li>
          <li>Tom stated that, by the time 2D graphics is standardized,
            we should be able to get good conversion routines in
            the standard library or we will have failed miserably!</li>
          <li>Hubert observed that the paper is missing bidirectional
            language support.</li>
          <li>Tom noticed that the paper doesn&#39;t say what happens with
            ill-formed encoded input.</li>
          <li>Mark suggested discussing font names; these should
            probably be bag-of-byte names. The paper defers to the HTML
            CSS specification.</li>
          <li>Zach noticed that the paper doesn&#39;t discuss normalization.
            It would be nice if it called it out specifically.</li>
          <li>Tom asked if normalization matters.</li>
          <li>Zach responded that it does in some cases.</li>
          <li>JF suggested that we should make it possible to defer to
            the CSS specification if we can&#39;t right now. We don&#39;t
            want to do what we previously did in forking the Unicode
            identifier specification from
            <a href="https://unicode.org/reports/tr31" rel="nofollow noreferrer noreferrer" target="_blank">UAX#13</a></li>
          <li>Mark noticed that some of the interfaces pass and return <code>std::string</code>
            by value where they probably shouldn&#39;t.</li>
          <li>JF pondered about overlap with SG13 and avoiding conflicts
            in scheduling when meeting in Cologne.</li>
          <li>[Editor&#39;s note: SG13 and SG16 are meeting on separate
            days.]</li>
        </ul>
      </li>
    </ul>
    <p>Tom.<br>
    </p>
  </div>

_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" rel="noreferrer noreferrer" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer noreferrer noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div>