[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sylpheed
Subject:    [sylpheed:23906] Re: Sylpheed 1.0.1 (stable version) and 1.9.0
From:       Milan =?ISO-8859-1?Q?Holz=E4pfel?= <lists () mjh ! name>
Date:       2005-01-29 13:53:20
Message-ID: 20050129145320.5a5dcd4f.lists () mjh ! name
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 28 Jan 2005 12:32:10 +0100
Godwin Stewart <gstewart@bonivet.net> wrote:

> [...]
> 
> The main drawback making me stay with GTK+1.2 sylpheed at the moment is a
> problem with 8-bit characters that shows with the unofficial GTK+2 port.
> 
> If you view an e-mail containing 8-bit characters normally all is well.
> 
> If you view the e-mail source (Ctrl-U), all lines in the body containing
> 8-bit characters are simply not displayed. Does the official GTK+2 port also
> exhibit this weirdness?

The source of an eMail has no encoding specified.  Viewing the source of
an eMail is actually equal to opening a text file in your favourite
editor:  The editor will use exactly one encoding to get the text out of
the stream of bytes.  

Both eMail encoded in UTF-8 and encoded in some Latin-charset will
display fine however, because the format of the eMail tells the mail
reader that a specific part of the stream of bytes was be encoded using
the specified charset.  This information is used if you view the mail.
If you view the source however, there is actually no reason for the
email program to use this information, since it is the source itself
which you want to be shown.  

But it seems somewhat strange that the GTK+-1 version will treat the
stream of bytes of an eMail source as being Latin (probably acc. to your
locale) and that the GTK+-2 version, on the other hand, will treat it as
UTF-8 (therefore the Latin charset's non-ascii-chars are invalid and not
displayed.) 

The source viewer may use the encoding information provided for the
different text parts of an eMail, but this starts to defeat the purpose
of a source viewer to some extend, since the source is processed before
it's presented.  A technically cleaner solution might be to use some
escape character for any bytes > 127, may it be "." or "?" or whatever
(and a graphical app might even use coloured character or sth.)

Regards,
Milan


- -- 

                   Milan Holzäpfel alias jagdfalke alias jag

Antworten direkt an mich                             Answers directly to me
gehen bitte an eine Addresse,                        go to an address one
die man hier finden kann:                            can find here, please:

Kontaktinfos sowie                                   Contact infos as well as
Öff GnuPG-Schlüssel    <URL:http://con.mjh.name/>    GnuPG Public Key
GnuPG Fingerabdruck     4C8A 5FAF 5D32 6125 89D1     GnuPG Fingerprint
                        0CE5 DB0C AF4F 6583 7966



                    http://www.deppenleerzeichen.de/                        


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB+5VQ2wyvT2WDeWYRAl3mAKCUEqvE9VQqiVCOLyYXELioCeYGBwCZAU3X
hHE3yu5eObU+w9gXpqCUbAg=
=JL2J
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]