<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 <<a href="mailto:tom@honermann.net" target="_blank" rel="noreferrer">tom@honermann.net</a>> 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'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'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'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't right now. We don'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't.</li>
<li>JF pondered about overlap with SG13 and avoiding conflicts
in scheduling when meeting in Cologne.</li>
<li>[Editor'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>