Hi Peter: Am 26.04.08 16:44 schrieb(en) Peter Bloomfield:
One solution would be to convert a message containing lines with rtl context into html, with a sequence of rtl lines wrapped in <div dir="rtl">...</div>.
That sounds like a good solution to me! However, we should create the message as multipart/alternative, with one text/plain and a second text/html part in this case - just to be nice to plain-only mailers! The text/html should probably simply contain a series of <p>...</p> containers, right? Maybe even the syntax highlighting could be used (i.e. *bold* → <b>bold</b> or the equivalent span, etc.).
Just a dumb question, though - is there a function to determine whether a utf-8 char is rtl or ltr? How does Pango do that? I couldn't find one in glib...
Rich text is a lighter-weight format than html, but I don't know whether it has any corresponding construct.
It has - at least according to the online docs <http://msdn2.microsoft.com/en-us/library/aa140283(office.10).aspx>, and the Max OS X Textedit application (the standard editor there) which uses rtf as native format does support it. However, if you look at the documentation, I don't think it's actually lighter than html... I don't like html either, but constructing a message body seems to be rather simple (see above). Furthermore, more standard mailers are able to display html than rtf.
Since the converted message would no longer be viewable by a non-html-enabled mail reader, conversion would have to be somehow optional.
See above - use multipart/alternative, with first plain, and then html. Quoting from rfc 2046 (section 5.1.4, "Alternative Subtype"):
<quote> Systems should recognize that the content of the various parts are interchangeable. Systems should choose the "best" type based on the local environment and references, in some cases even through user interaction. As with "multipart/mixed", the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system's local environment. </quote>There should be a check button in the Options menu and/or in the preferences to enable the optional HTML parts. However, this approach has one serious drawback, as it will break the current implementation of RFC 2440 (aka old OpenPGP) encryption which works for single parts only. I am already thinking about an extension which would /separately/ sign or encrypt every part. The message structure would still be visible, but it's better than nothing. Don't attach the file "Plan to kill Bush.txt", though - it would then be encrypted, the file name is still be readable ;-)
This would also make Balsa more compatible with the g10code plug-in for M$ Outlook <http://www.g10code.de/p-gpgol.html> which I *think* does the same (I _never_ use Outlook ;-).
Just my € 0.01, though... Cheers, Albrecht.
Attachment:
pgp5UpHoSXMCM.pgp
Description: PGP signature