EML export destroys messages readability
-
We use Microsoft Office 2013 with a kopano server (still bound to it via MAPI). For some reasons, I need to process some of the mails using Microsoft Outlook 2007! For some other reasons I have to go the following route:
Export the message as EML directly from kopano (e.g. by python). Transform this message again in MSG format by an external program. Read the MSG in MS Outlook 2007.
Outlook 2007 is stuck on displaying the HTML body. The headers are shown already, though.
I have tried displaying a MSG file exported via MS Outlook 2013 and read in with MS Outlook 2007: it works (no EML export by kopano).
I have transformed the EML generated by kopano using MS Outlook 2013 into a MSG file and read it in with MS Outlook 2007: same problem as described above.
MS Outlook 2013 itself can display the message, but needs considerably more time (it seems to be doing someting in the background). However, I need MS Outlook 2007 to do the same.
The email is nothing special but has at least one Asian font.
It seems that on the export done by kopano something happens, what affects readability of the emails.
Btw. I have also tried exporting to EML via Webapp and transforming to MSG: again it does not work.
Any idea? For me this is nearly a showstopper.
-
Hi @marlemion,
@marlemion said in EML export destroys messages readability:
Transform this message again in MSG format by an external program.
have you checked if that second conversion could be the culprit?
In the past you had questions about compiling Kopano yourself, is that with your build or with one of ours? Which version are you using at all?
@marlemion said in EML export destroys messages readability:
For me this is nearly a showstopper.
If this is impacting your business use of Kopano, I’d recommend to get in direct contact with our support.
-
Hi,
thanks for your reply.
You are correct that I use (partially) self compiled components. However, I have tested the webapp eml export. This webapp is not self-compiled, but rather your packages provided for centos (distributed through our IT service).
Hence, I can conclude that my self-compiling is not the culprit.
As regards EML->MSG conversion I tested the following:
I used two programs: MS Office 2013 and MailConverter.exe (from Rebex). Both result in the same problem. Hence, I conclude that the conversion is not the problem. However, this is not a secure evidence. Hence, I did some more:
Compared the HTML of the email as provided without export with the HTML of the exported EML.
There is a difference. As I set out in the previous email, the message partially uses Asian fonts. Hence, these fonts are referenced in HTML tags as fontname=<ASIAN characters>. So YES they are referenced in non-standard characters.
When looking at the EML HTML code, these characters have been transcoded by kopano to html encoded chraracters (such as #xxxx;). This would be ok for displayed text, but not for fonts.
Hence, this might be the culprit. Transcoding HTML tags seems to be odd for me at least.
However, as we have support through our IT service, I will pass this on to them. Thanks so far!
-
It seems to be a character set problem. The problematic email is encoded in ‘gbk’. I have found an ugly workaround for emails in this encoding:
I export the email into EML via kopano and read that EML in as an email.message (I am on python). If the encoding of the kopano object is ‘gbk’ I get the utf8 encoded html representation from kopano (i.e. mail.html_utf8), encode it as bas64 and set it as the payload carrying the html content (text/html). After that, I set the character set of this payload to ‘utf8’.
Hence, for now, I have found a solution to my problem.
