Date: Thu, 31 Oct 2019 19:08:01 -0400
Hello all!
P0267R10 (2d graphics) is in the pre-meeting mailing. It doesn't contain
much that's new as far as text and Unicode are concerned. The reason for
this is that I wanted to get proactive feedback from all of you rather
reactive feedback.
Below are some thoughts and questions I sent to Tom so he could decide how
best to present them, and he recommended sending it to this DL.
Without further ado, here they are.
I've been contemplating how to add support for grapheme clusters (glyph
collections) to the 2d; specifically desired features and functionality.
It's relatively easy to just add a glyph collection type (with each glyph
collection object containing one or more Unicode glyph values that defines
what will be rendered as a single character). A collection of objects of
that type could then be passed as a pair of iterators or an
initializer_list to the draw_text member function for the surface types.
My initial questions for SG16 are:
Does this seem like the right direction to go?
If so, starting from a glyph collection object being an opaque type, what
functionality/details should be exposed from that type to make it useful?
Does it seem right to have the values contained in a glyph collection
object be a set of one or more uint_32 values? And if not, why not?
Best regards,
-Mike
P0267R10 (2d graphics) is in the pre-meeting mailing. It doesn't contain
much that's new as far as text and Unicode are concerned. The reason for
this is that I wanted to get proactive feedback from all of you rather
reactive feedback.
Below are some thoughts and questions I sent to Tom so he could decide how
best to present them, and he recommended sending it to this DL.
Without further ado, here they are.
I've been contemplating how to add support for grapheme clusters (glyph
collections) to the 2d; specifically desired features and functionality.
It's relatively easy to just add a glyph collection type (with each glyph
collection object containing one or more Unicode glyph values that defines
what will be rendered as a single character). A collection of objects of
that type could then be passed as a pair of iterators or an
initializer_list to the draw_text member function for the surface types.
My initial questions for SG16 are:
Does this seem like the right direction to go?
If so, starting from a glyph collection object being an opaque type, what
functionality/details should be exposed from that type to make it useful?
Does it seem right to have the values contained in a glyph collection
object be a set of one or more uint_32 values? And if not, why not?
Best regards,
-Mike
Received on 2019-11-01 00:08:32