[OT] Re: has sourceforge exposed the dirty little secret ?

[Chris Angelico]

On Mon, Jan 8, 2018 at 11:07 AM, Gene Heskett <gheskett at shentel.net> wrote:
> On Sunday 07 January 2018 18:25:52 Random832 wrote:
>
>> On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote:
>> > But it also says:
>> >
>> > Content-Transfer-Encoding: 7bit
>> >
>> > Which is incorrect, as the message is actually 8bit encoded (since
>> > the Emoji aren't in the first 127 characters, so their UTF-8
>> > encoding isn't 7-bit. Some software might have messed up the message
>> > in transit due to that error.
>>
>> Well, the fact that the emoji survived the round-trip and showed up
>> properly in his reply (and yours) led me to rule out the possibility
>> that anything like that had happened. Plus, if that had happened, the
>> result wouldn't be boxes, but a series of ASCII characters (some of
>> which are control characters, and some of which are printable).
>
> Its just boxes here, and I just spent the better part of half an hour
> trying all the fonts available to kmail, without see anything but
> variable sizes of twin boxes. Looking at the raw message its also marked
> transfer content encoding = base64, which I'd assume destroys any
> semblance of an 8 bit encoding.

Proper font substitution would mean that, no matter which font you
have selected, unknown glyphs will be drawn from some other font that
supports them. So you probably don't have any font installed that has
those glyphs. That should be a solvable problem, though it'll depend
on finding one that you like.

Transfer encoding of base64 just means that eight-bit encodings get
wrapped up in a four-for-three carriage method. You take three bytes
and represent them in four letters. It's an encoding that can be used
for binary files or eight-bit text alike. Doesn't change the content
itself; once you decode base64, you get back a series of bytes, which
can be decoded into Unicode text by the normal methods.

ChrisA