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



Hi Peter!

Am 26.04.08 19:13 schrieb(en) Peter Bloomfield:
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>.

Since glib 2.14 this function does roughly the same, but we had to look up the proper direction ourselves: <http://library.gnome.org/devel/glib/2.14/glib-Unicode-Manipulation.html#g-unichar-get-script>.

BTW, if I interpret the HTML 4.01 trans standard correctly, the "dir" tag should /not/ be necessary, as the html renderer is supposed to determine and display the proper direction automatically for unicode chars (see <http://www.w3.org/TR/html401/struct/dirlang.html#h-8.2>).

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.

Ah, I see! But there is again the same problem: does the "Persian" web browser support it? I'm afraid it will treat it as text/plain...

Would it be unacceptable to simply not offer signing for multipart messages?

Currently, a warning pops up if the user tries to rfc 2440 sign or encrypt a message with attachments. The solution is to /manually/ (seahorse, nautilus) sign or encrypt the attachments and then attach the signed or encrypted file. This will of course fail if Balsa produces the "attachment", i.e. it must be handled within the composition process.

An other problem is that I don't know how to sign a text/html part. The "magic" rfc 2440 headers had to be within the html body (as otherwise the html parsers would be broken), but then the body is difficult to parse. Html is simply outside the scope of '2440! Probably the best approach is - sign only: sign the text/plain message body, and show the user the warning dialogue; - encrypt or sign and encrypt: sign and encrypt each part separately, attach the message text as text/(plain|html), and all "real" attachments as application/pgp-encrypted.

But this is only the second step...

Cheers, Albrecht.

Attachment: pgpFjZbrvJZ0n.pgp
Description: PGP signature



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