[SG16-Unicode] SG16 review of P0267R9 - 2D graphics

Corentin corentin.jabot at gmail.com
Sun Jul 14 09:10:35 CEST 2019


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 honermann.net> 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 isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/unicode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/unicode/attachments/20190714/3c292ae5/attachment.html 


More information about the Unicode mailing list