Um, no, what I meant was is that 50% grey (alternate pixel filled-in)
character what is actually being received in Mudlet or does it just
represent a replacement character put in somehow (as an alternative to
say '�', the 'proper' replacement character a.k.a. codepoint U+FFFD)
Reason I was asking was to see if there is any plusable way to get from
a single byte character to something that takes three bytes to encode.
One faint possibility might be that if the 'W' is the *very* *first*
byte of the incoming stream, if so, could the three bytes of a Byte
Order Mark - 0xEF,0xBB,0xBF be mixing up with the 0x57 for 'W' to
produce something weird...
That is a long shot though, and the mechanism causing it is beyond me at
the moment. I think we might need to know the OS and locale settings for
people having this bug - and some idea of who does not. (Beyond that
they are on 2.1)
On 22/09/14 20:08, Vadim Peretokin wrote:
> It is being rewritten, it should be a 'W' and was a 'W' in 2.1.
>
> On Mon, Sep 22, 2014 at 11:46 PM, Stephen Lyons <email address hidden>
> wrote:
>
>> The odd character here is coming up as Unicode point U+2592 "MEDIUM
>> SHADE" - in Utf-8 that would be the three byte sequence 0xE2 0x96 0x92
>> or if utf-16 - which might translate to Qt internal format for QChar(
>> 0x2592 ) but I'm not certain of that. Is this the actual character or
>> has it been rewritten by being copied to here?
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1369505
>>
>> Title:
>> Connecting to an IRE MUD changes 'W' to a ''
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/mudlet/+bug/1369505/+subscriptions
>>
>
Um, no, what I meant was is that 50% grey (alternate pixel filled-in)
character what is actually being received in Mudlet or does it just
represent a replacement character put in somehow (as an alternative to
say '�', the 'proper' replacement character a.k.a. codepoint U+FFFD)
Reason I was asking was to see if there is any plusable way to get from
a single byte character to something that takes three bytes to encode.
One faint possibility might be that if the 'W' is the *very* *first*
byte of the incoming stream, if so, could the three bytes of a Byte
Order Mark - 0xEF,0xBB,0xBF be mixing up with the 0x57 for 'W' to
produce something weird...
That is a long shot though, and the mechanism causing it is beyond me at
the moment. I think we might need to know the OS and locale settings for
people having this bug - and some idea of who does not. (Beyond that
they are on 2.1)
On 22/09/14 20:08, Vadim Peretokin wrote: /bugs.launchpad .net/bugs/ 1369505 /bugs.launchpad .net/mudlet/ +bug/1369505/ +subscriptions
> It is being rewritten, it should be a 'W' and was a 'W' in 2.1.
>
> On Mon, Sep 22, 2014 at 11:46 PM, Stephen Lyons <email address hidden>
> wrote:
>
>> The odd character here is coming up as Unicode point U+2592 "MEDIUM
>> SHADE" - in Utf-8 that would be the three byte sequence 0xE2 0x96 0x92
>> or if utf-16 - which might translate to Qt internal format for QChar(
>> 0x2592 ) but I'm not certain of that. Is this the actual character or
>> has it been rewritten by being copied to here?
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https:/
>>
>> Title:
>> Connecting to an IRE MUD changes 'W' to a ''
>>
>> To manage notifications about this bug go to:
>> https:/
>>
>