Date: Thu, 15 Sep 2022 16:59:49 -0500
I found the context. Sorry for the quick second post
https://www.unicode.org/reports/tr11/#Scope
Quote:
> Note: The East_Asian_Width property is not intended for use by modern terminal emulators without appropriate tailoring on a case-by-case basis. Such terminal emulators need a way to resolve the halfwidth/fullwidth dichotomy that is necessary for such environments, but the East_Asian_Width property does not provide an off-the-shelf solution for all situations. The growing repertoire of the Unicode Standard has long exceeded the bounds of East Asian legacy character encodings, and terminal emulations often need to be customized to support edge cases and for changes in typographical behavior over time.
hope this helps.
https://www.unicode.org/reports/tr11/#Scope
Quote:
> Note: The East_Asian_Width property is not intended for use by modern terminal emulators without appropriate tailoring on a case-by-case basis. Such terminal emulators need a way to resolve the halfwidth/fullwidth dichotomy that is necessary for such environments, but the East_Asian_Width property does not provide an off-the-shelf solution for all situations. The growing repertoire of the Unicode Standard has long exceeded the bounds of East Asian legacy character encodings, and terminal emulations often need to be customized to support edge cases and for changes in typographical behavior over time.
hope this helps.
-- Steven R. Loomis Code Hive Tx, LLC https://codehivetx.us > On Sep 15, 2022, at 4:58 PM, Steven R. Loomis <srl295_at_[hidden]> wrote: > > Hi. Briefly, we’ve discussed this issue a little bit at UTC, and I’ve tried to engage terminal emulator vendors, who are who probably need to be part of the discussion. > > I’m not sure about "Lack of explanation in the standard”, I think wording was added to make these updates out of scope. > > I can try to dig up previous discussion if needed. > > -s > > -- > Steven R. Loomis > Code Hive Tx, LLC > https://codehivetx.us <https://codehivetx.us/> > > > >> On Sep 14, 2022, at 4:28 AM, Corentin via SG16 <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote: >> >> Hey folks. >> >> How was the table of width in [format] derived? >> http://eel.is/c++draft/format#string.std-12.sentence-3 <http://eel.is/c++draft/format#string.std-12.sentence-3> >> >> We have 2 issues here: Lack of explanation in the standard makes it hard to evolve that table, >> and it does require maintenance as the Unicode standard evolves. >> >> Reading the intent of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1868r2.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1868r2.html>, >> >> We do want: >> To treat 0-width codepoint as 1 >> To treat emojis as 2 >> To treat full width east asian as 2. >> https://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c <https://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c> >> >> I think a better specification would be given that we have a floating reference to UAX44, >> to say that codepoints that have the Unicode property "Emoji_Presentation" or >> East_Asian_Width="W" have a width of 2. >> >> This ensures implementation remains coherent as Unicode evolves. >> >> Thanks, >> Corentin >> >> >> >> -- >> SG16 mailing list >> SG16_at_[hidden] <mailto:SG16_at_[hidden]> >> https://lists.isocpp.org/mailman/listinfo.cgi/sg16 >
Received on 2022-09-15 21:59:52