Created attachment 43079 [details] [review]
patch to enable Thai/TIS-620 support

kitt: you must submit your patch to evolution-patches@ximian.com for
review.
Maybe you have to subscribe to that list. To do so, check
http://lists.ximian.com

reassigning to harish; patch needs rework, still missing in current cvs (evo
version 2.3.8)

Created attachment 51458 [details] [review]
updated, untested patch to enable Thai/TIS-620 support

updated patch of the former, obsolete one (camel location changed to e-d-s)

the list of charsets in the table in camel-charset-map.c is not something that
should be changed without a lot of careful thought and testing because it is
very fragile. also, the charsets in that table must remain 8bit and not include
any multibyte.

The table has a very important order.

so, jeff, any ideas? shall i revert harish's "accepted-commit_now" setting on
the patch?

changing patch status to commented_on

TIS-620 is plain 8bit and not multibyte, for that concern.

setting priority to urgent - we're heading string freeze.
i'd really like to see a conclusion to give thai people the ability to use evolution. :-/

the e-charset-picker.c portion of the patch is fine and I'd recommend committing that portion.

However, the camel-charset-map.c part I'm unconvinced is necessary and is likely to introduce breakage (for example, Evolution might choose to encode something in TIS-620 instead of iso-8859-* or windows-cp125* which are much more common charsets)

committed the UI part:
http://cvs.gnome.org/viewcvs/evolution/widgets/misc/e-charset-picker.c?r1=1.23&r2=1.24

need to discuss the camel-charset-map.c part.

lowering priority a bit now.

thep, any chance to attach a sample thai message (please remove any confidential data before)?

thep?

any progress? otherwise i have to outcomment the strings for evo2.6.

Sorry for replying late. My evo build just crashes too easily to test
anything. (For other evo patches, I can test their functionalities in
tiny seperate programs.) So, I ask Kitt (the bug reporter) to do that.

However, IMO, having TIS-620 in the menu should be enough for reading
TIS-620 encoded Thai mails. I guess the camel code is for character set
detection, right?

thep: i have no idea of thai and i don't have a sample message. can you please test this?
gnome 2.14 is only 10 days ahead and i have to outcomment the string otherwise.

Created attachment 60372 [details]
test message

Please try this message.

Sorry again for the delay.

Created attachment 60373 [details]
test message

Please try this message.

Sorry again for the delay.

Created attachment 60374 [details]
The UTF-8 version, for comparison

Could you compare the apperance with this UTF-8 version?

Really, I wish I could start my evo build to test it myself. But there must be something wrong in my configuration. So, I have to ask for your help to test.

I have only evolution 2.4.1 in my hand right now so I report this based on 2.4.1. 

AFAICT, evolution cannot display a TIS-620-encoded message correctly if its content is specified as ISO-8859-1. This kind of mails exists, I believe, because ISO-8859-1 is the default encoding for many mail clients. Thai people just use it to compose Thai messages, and somehow, it works fine for them.

The only way I can read such mails on evolution is to force to display as TIS-620. So, having TIS-620 in the encoding menu really helps.

note for anyone testing this: one has to add one line, like
               From example@example.com Wed Feb 26 15:32:08 2004
to the beginning of those two examples messages so they can be imported into evolution.


both messages are displayed absolutely perfectly here (evo 2.5.92), i did not had to change anything (ok, my character encoding setting is set to default, but of course it also works when chossing tis-620)!

that's very cool. :-)

so kitt, thep, how to proceed further? do you think this bug is fixed, or is anything still missing? "WORKSFORME". :-)

kitt: any example message handy for the case you're describing that you could attach here (please remove confidential data before)? thanks in advance.

Created attachment 60493 [details]
test mail, without encoding header

Oops, I forgot to change the encoding header before posting. It was perfectly correct mail and needed no enforcing, thus not suitable test case. Please try this one instead.

Created attachment 60494 [details]
test message, incorrectly encoded as iso-8859-1

Simulating Kitt's case. Maybe, Kitt can also provide a real one.

Created attachment 60504 [details]
Sample mail - ISO-8859-1

This is an example of mail that I have to select TIS-620 from encoding menu to read it. Actually, it has 3 parts, I cut two of them and provide only text/plain.

whilst i can view thep's two example mails without any problems (YEEHAH! well, after manually setting the character encoding to tis-620), i am unable to view kitt's mail. perhaps it has been mangled when you set the mime type to "application/octet-stream" instead of "text/plain" by accident? hard to say. :-/

kitt, i also doubt that it's a valid mail since you've cut it - it says "Content-Type: multipart/mixed" at the beginning, but the second bounty in the message body is obviously missing. can you provide a complete one and add the correct mime type? thanks very much in advance... :-)

Created attachment 60526 [details]
Sample mail - the whole message

This is the whole message of the previous. I 'save as' and change only the sender/cc to example@example.com.

kitt, except for the subject it works.
hmm.

the header is broken, see the source: "X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char C3 hex) in message header 'Subject': Subject: ..."

so... closing as fixed?

According to your test results, the bug seems to be fixed. Although the correct encoding detection for the case of unspecified encoding (by the patch to camel?) might be another benefit, but let's do it in later versions.

ok, great so far. thanks everybody for your patience, and have fun with evolution-2.6 then :-)

the camel charset table is for outgoing encodings only, it is not applied to inbound email.