To add some data point, Qt, gtk, skia, SDL, Cocoa and others expect utf-8
encoded text.

On some platform conversation are required and there may be several
conversions depending on what the encoding of the font used to render is.


I would caution against designing an API intended to communicate with human
beings that would make it painfully difficult to do so.

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

On Sun, Jul 14, 2019, 6:10 AM Tom Honermann <tom_at_[hidden]> wrote:

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