Re: KMail and characters sets (=20 problem)

On Tuesday 15 March 2011 08:29:22 Ingo Klöcker wrote:
> Hi,
> 
> please don't crosspost, i.e. choose either kdepim-users or kde-pim, but
> not both. Thank you!
> 
> Your questions should have been answered by Thomas on the kde-pim
> mailing list. I strongly support Thomas recommendation not to worry
> about the encoding. Let KMail choose a suitable encoding for your
> messages.
> 
> 
> Regards,
> Ingo
> 
> On Monday 14 March 2011, Peter wrote:
> > Hi,
> > 
> > Some emails being sent from KMail refuse to use the char set defined.
> > 
> > Some lines end in
> > 
> > = , and then the next line starts in
> > 
> > =20
> > 
> > and there are a whole lot of lines with "=20" in them.
> > 
> > The emails with the 'garbage' have this in the headers
> > 
> > MIME-Version: 1.0
> > Content-Type: Text/Plain;
> > 
> >   charset="utf-8"
> > 
> > Content-Transfer-Encoding: quoted-printable
> > 
> > and the emails that look okay have this
> > 
> > MIME-Version: 1.0
> > Content-Type: Text/Plain;
> > 
> >   charset="iso-8859-1"
> > 
> > Content-Transfer-Encoding: 7bit
> > 
> > or sometimes a charset of us-ascii I think.
> > 
> > Is there anyway way to FORCE either is-ascii or iso-8859-1
> > 
> > What characters will make the email contain garbage ? Like wjat about
> > quotes, single quotes, underlines, dashes, double equal signs, etc,
> > etc ??
> > 

I never received the reply from Thomas, however I can see it in the archives. 
I was looking at the raw format, because I needed to copy the raw data to 
another computer, and the 'save as' exported all the garbage, not what I 
wanted. I wanted just the clear plain text.

I see Thomas said:

> You should really not worry about encoding issues, using non-ASCII
> characters is understood by virtually every mail client today, MIME
> encodings like qouted-printable have been around for more than a decade.

Okay, my concern was continuing along the lines of what i saw in the 'save 
as', and didn't want that sort of 'garbage' being 'seen' by the recipients. 
However, if you are 100% certain that people will not see it, but only see the 
plain text (non-html anyway), then that is okay.

Couldn't understand why KMail , on the auto-detect would go utf-8 anyway, as I 
looked down the 'us-ascii' chart on one site, and all the characters I used in 
the email were specified in that chart. Simply meaning, allthe chars in the 
email were of the us-ascii , so why would KMail go ..

   charset="utf-8"
 Content-Transfer-Encoding: quoted-printable

.. beats me. Anyway, I will leave it on 'auto etect' as it has been

Under Composer, Charset TAB, the order is

iso-8859-1
us-ascii
utf-8 (locale)
utf-8

but I guess 'auto detect' overrides that. One area that did give me concern 
though, is when KMail was 'forced' to (say) us-ascii, a msg appears like 
'chars will be lost', I press okay amd send, but email seems okay. However, if 
I wait a few more seconds, the email in composer mode turns out complete 
rubbish, all formatting is lost, many characetsr have been changed, etc.

So, what I'm saying is, if I do use "force" the encoding, I have to send it 
within a few seconds, otherwise the whole email is clobbered, but at least the 
'edit undo' is there.

Bottom line is, if people are 100% certain that the recipients will not see 
the encoding (in raw format, it is impossible to read, well almost), then I 
will simply let KMail auto detect.

I wonder what this will be sent as, there are no special chars, so us-ascii 
should be okay.

Peter
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users