Re: HTML support (was: Please Support Right To Left Direction)

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:>.

> 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
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:> 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"):

    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.

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 <> 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]