Hi Albrecht! On 04/26/2008 12:21:05 PM Sat, Albrecht Dreß wrote:
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!
Oh, that's right--that's what mime structuring is all about, isn't it?!
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.).
Yes, I suppose we have to give it some minimal HTML markup, to get it to look right.
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...
I stumbled across these: pango_unichar_direction () and pango_find_base_dir (), at <URL:http://library.gnome.org/devel/pango/1.10/pango-Text-Processing.html>.
> 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.
Hmm--I was thinking of text/enriched <URL:http://www.faqs.org/rfcs/rfc1896.html> rather than application/rtf, but the rfc doesn't refer to bidi at all, and I couldn't find any followup to it.
> 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.
That sounds right.
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 ;-).
Would it be unacceptable to simply not offer signing for multipart messages?
Attachment:
pgpWo22pNj8w5.pgp
Description: PGP signature