[Standards] Council Minutes 2020-05-27

Sam Whited sam at samwhited.com
Wed Jun 3 00:13:58 UTC 2020


But presumably this doesn't happen in XMPP clients and the like, which
do UTF-8 correctly? If this is just Windows being stupid and using UTF-
16, I don't think it's something we should bother with.

Then again, this isn't something that needs to be specified and since
we're not sure maybe it's worth just not mentioning it. If people
want to develop toolbars that use this technique or something, they
still can.

—Sam

On Tue, Jun 2, 2020, at 18:46, Tedd Sterr wrote:
>  On Windows, the ZWSP is handled correctly in many places, but badly
>  or not at all in others.
>
>  Depending on version and options, the RichEdit control may display no
>  space (good), a '?' (as unknown character), a full space, or a full
>  space *after* the following character. It also displays as a full
>  space in the console.
>
>
> *From:* Standards <standards-bounces at xmpp.org> on behalf of Tedd Sterr
> <teddsterr at outlook.com> *Sent:* 02 June 2020 21:20 *To:* XMPP
> Standards <standards at xmpp.org> *Subject:* Re: [Standards] Council
> Minutes 2020-05-27
>  > You don't need special handling, …
>  True; of course I realised my mistake immediately after sending.
>
>  Once, I had the great idea of using ZWSP to demarcate sections of
>  text that would be omitting during copying, but ended up having to
>  use something less fancy because it caused problems (it might have
>  been a display issue, possibly something else - I'll have to do some
>  testing.)


More information about the Standards mailing list