GNOME Bugzilla – Bug 148550
Implement e-mail link
Last modified: 2006-10-18 20:20:49 UTC
Gnumeric support hyperlink features but the current html plugin ignores it. MS Excel can export well. So Gnumeric should support it. And you can input newlines in a Gnumeric/Excel cell with Alt+Return. But the current html export plugin ignores them. It should support that feature.
Created attachment 29928 [details] [review] diff for gnumeric/plugins/html/html.c The patch is for the CVS HEAD 2004-07-27.
The patch looks good to me. Let's get a 2nd opinion and potentially apply to 1.2.x too.
I have reviewed the patch and committed it to cvs HEAD. I think it is straight forward enough to also go into 1.2.x.
On further reflection it's not quite so simple. We should only export certain types of links. Links into the current workbook aren't likely to be useful in html in our current syntax.
Created attachment 29987 [details] [review] Patch to restrict export to URLs. This patch restrict exports to URLs. It has already applied to cvs head and should be applied to 1.2.x after the previous patch has been applied.
email and potentially file links could work too. I suspect that all we need to do is check != gnm_hlink_cur_wb_get_type
email and file links do not work inside gnumeric. In fact you can't even insert e-mail links. In any case I think we should specifically allow specific link types and make sure they work in the exported file, rather than just excluding one.
How can I help you to support email and file links in gnumeric?
For mailto:, you need to think about two levels of encoding. Address, subject and whatever else you allow in mailto have to be encoded. (I believe a mailto may even include a message body). 1) Encode each header according to mime rules (quoted printable ...) 2) The mime encoded strings are in the subset of ASCII which is acceptable for rfc821/rfc822 email. These intern will have to be quoted according to url quoting rules. I believe 2) is straightforward using libxml2 mechanisms. For 1) we must grab or write code. Everything we need is in evolution :-)
camel/camel-mime-utils.c in evolution seems to have the stuff we need for mailto urls. 4277 lines long.
I have been overlooking some obvious points while reading rcf2368 about mailto URLs. - When exporting to XL, XL rules apply. - When exporting to OOo, OOo rules apply. - When exporting to Gnumeric format, we make our own rules. - When exporting to html, rfc2368 has to be taken literally. - And finally, there is the question of how to invoke a mailer using the URL. rfc2368 mandates MIME encoding of headers (RFC2047), i.e. Subject: =?iso-8859-1?Q?Frigj=F8ring_av_bergen-gw5?=. Excel uses Excel's character encoding. OOo uses the xlink href attribute. This specification uses UTF-8 in URL's - forbidden according to the rfc for URI's (rfc 2396), and specifies an escape procedure "when passing the URI reference to a URI resolver". A mailto: imported to OpenOffice is stored as xlink:href without MIME header encoding. If we apply the xlink:href escape procedure to this, we end up with what looks like a mailto url, but still without MIME encoding. This is invalid, so I think OOo has a bug. But as long as we don't claim to implement xlink:href, we are free to specifiy that mail headers are *not* MIME header encoded in the Gnumeric format. There is no standard for how to invoke a mailer. There is experience about what works and what does not. On UNIX, the easiest way may be to invoke the mailer from a user modifiable script. Distros may adapt this to their default mailer. May be there should be a Freedesktop standard about this. Mime header encoding will then be necessary only when exporting to html, and if we want to be more correct then OOo when exporting to OOo. Both are low priority enhancements.
I can implement subject mime encode/decode by myself, but I don't think gnumeric needs mime encoding to its mailto support, because mailer will do it. From command line, % evolution mailto:ynakai@redhat.com?subject=nihongo and it encodes the subject correctly. To invoke mailer, we need to implement simliar codes like gnome_url_show(), and we should use mailer of which gconf assigns for key "/desktop/gnome/url-handlers/mailto/command".
gnome_url_show() handles mailto: url, actually.
The attached patch adds email handling callbacks and move the FIXME message. It can export email link to html too. Excel does not check email address format. It allows a Japanese string without @ mark.
Created attachment 30918 [details] [review] diff for src/dialogs/dialog-hyperlink.c
Created attachment 30919 [details] [review] diff for src/dialogs/dialog-hyperlink.c Updated patch. "Send Email" is not correct. "Email Link" is the correct text on GUI.
Created attachment 31069 [details] [review] diff update Add codes to respect rfc2368. I don't think rfc2047 is neccessary because rfc2368, mailto url scheme definition, doesn't refer rfc2047. And evolution doesn't support rfc2047 style mailto argument.
I've been looking at nalin's latest patch. It looks pretty good. Here are some comments: url_encode, url_decode. They will be needed in other places, at least in the excel plugin. I think they belong in libgoffice or libgsf. Jody? url_decode looks good. dhl_set_target_email will parse the form: "mailto:hellan@acm.org?subject=hello". It should also handle "mailto:?to=hellan@acm.org&subject=hello", which is equivalent. "mailto:?subject=hello&to=hellan@acm.org" is equivalent to both. Finally, there could be other headers in the url: "mailto:hellan@acm.org?subject=hello&cc=snoop@nsa.gov" In this case, we shouldn't set subject to "hello&cc=snoop@nsa.gov". But it's probably OK to just ignore the extra header. dhl_get_target_email needs to encode the address, not just the subject. Address forms like "Jon Kåre Hellan <hellan@acm.org>" and "hellan@acm.org (Jon Kåre Hellan)" are valid and need encoding. dhl_get_target email returns a heap allocated string. Therefore, dhl_get_target must free it. That in turn means that the other dhl_get_target_xxx routines should strdup the strings they are returning. Re. the comments to the patch: > because rfc2368, mailto url scheme definition, doesn't refer rfc2047. Good catch. What it says is: "8-bit characters in mailto URLs are forbidden. MIME encoded words (as defined in [RFC2047]) are permitted in header values". This probably means that hex encoding of 8-bit characters is OK. e.g. Kåre -> K%E5re. I was reading it as if MIME encoded words were the only encoding, but it doesn't actually say that. > And evolution doesn't support rfc2047 style mailto argument. That's pretty important 8-). Good patch. Looking forward to the next version.
Comment on attachment 31069 [details] [review] diff update I've moved the encode/decode routines down into goffice/utils/go-file where they can get fleshed out and possibly moved to gsf later. The rest of the patch will be in 1.3.91. There's plenty of work to do, but this is a good start.
I am just adjusting the title of this bug report.
I'm closing this bug now. I've fixed the memory leak (comment 18). I also fixed a bug in the email dialog code. On close, subject was encoded, but not email. On open, it was the other way round. We can forget about RFC2047 header encoding in html export. Neither Firefox, IE or Opera supports it. There are still issues, but this is good enough until somebody complains.