| Index > Scribe > CODEPAGES | |
|---|---|
| Author/Date | CODEPAGES |
| Joerg 28/05/2002 6:30am | Since it is possible to switch between different codepages i have problems concerning the german "umlaute" (you know the a o u with the 'funny little dots') They are replaced by boxes in eMails i get from other people.
How can this happen, considering (as far as i understand) the codepage-setting within the "options" only has an effect on OUTGOING eMail. Did i get this right? So im asking myself, what codepage setting is the best recommendation for me in germany for my outgoing mails? Thanks for your help! |
| fReT 28/05/2002 8:33am | If it appears in the editor correctly then send me a mail and I'll check that it arrives ok.
Obviously put some umlaute's in the message for me to look at. Yes the codepage option is for outgoing email only. |
| Nick 28/05/2002 2:09pm | Well, I also have problems with my mails I recieve from my danish partners/friends (æøåü)
Until fRet is finding a solution I will recommend that you download and use version 1.63, it works both inbound and outbound (at least with ÆØÅ) Ciao |
| fReT 28/05/2002 7:54pm | I'm now thinking of a 2 stage approach to the whole problem.
Firstly I probably need to change the behaviour of replying/forward to [optionally?] use the default codepage instead of the codepage from the source email. The user expects to be able to type in the characters of the codepage they have selected. Even at the expense of the data from the source message being 'corrupted' by losing it's codepage. Now this brings up the real issue which is that under the current architecture I can't support the display of 2 blocks of text with different codepages inside the compose window at the same time. The editor has 1 codepage setting and that is fixed across the entire editor. I could build in styles that allow multiple codepages to be supported in the editor, or I could just buckle down and write in Unicode support. So that I can convert the 2 sets of 8bit+codepage text into 1 set of 16bit unicode text. Which the editor would display. Definately the 'cleaner' approach programatically. Now there are issues with this approach, I'd have to create 8bit+codepage to unicode mapping tables (not hard, just lots of work). And also I'd have to write the support into the editor and font sub-system. Then I'd have to port all the changes to Linux which may or may not support it. So all in all it's just a huge big headache that I don't want to deal with this week. So short term I'm going for the 'use default codepage' for all editing. Then as I get time slowly work on all the unicode support in the background. Oh not to mention setting up the LGI resource files for unicode. Another complete system that needs rewritting for unicode support. All in all patience is required. But I hear your pain :) |
| Standa 29/05/2002 4:32am | Excuse my poor english first :-)
To Nick & Joerg: If you have problems with incoming email, try to switch encoding to ISO-8859-1 or win1252 (right click menu in mail view window). If incoming e-mail uses ISO-8859-2 charset, there should be no problem. But if it uses windows-1252(1250) codepage, iScribe "recognize" it as us-ascii, so you must switch it manually to win1252(win1250). If you switch iScribe to any ISO codepage (and e-mail has windows-xxxx), you probably see boxes instead of some "accented" characters :-). Windows-xxxx codepages are often used by MS Outlook (Express) (can be switched to ISO). There is probably some problem (in iScribe 1.67) with multipart e-mails - text/plain part is probabaly already recognized as us-ascii :-( But I am not sure... BTW: If you change charset of incoming e-mail, you can save "modified" e-mail (save button :-). This is also needed if you want print "modified" email. |
| Nick 29/05/2002 5:24am | I know that I can change the codepage by right-click in the inbound mail and then choose win1252 and then saving the mail again. But you can't ecspect that normal folks (my friends who I have recommend i.scribe) shall do this with every mail they recieve because I know what there reply will be; - "I never had that problem with Outlook"
But now we know that "fret" is working against a solution :) |
| fReT 29/05/2002 7:11am | Standa:
I've changed the offical mime type for the windows codepages to windows-xxxx so it should detect incomming mail correctly. This change is available in the Scribe v1.68 beta. I'd be interested to know if it's working. |
| Reply | |