GNOME Bugzilla – Bug 355766
Multi-lang text in Body is not printed when composing in ASCII mode
Last modified: 2013-09-10 14:04:39 UTC
Please describe the problem: Multi-lang text in Body is not printed when composing in ASCII mode. Headers (cc/bcc/to/etc) get printed perfectly, but body gets printed with either random cars or nothing. Steps to reproduce: 1. Compose mail in Ascii format 2. Add काोेकाीेंक in the composer 3. Select print (or print preview) from the menu. Actual results: Nothing (or random characters) get printed from the body Expected results: printout should have been similar to what it was in body of the mail Does this happen every time? yes Other information: Printing from HTML mode works perfectly. Also, mails stored as drafts (in ascii mode) do not show this bug.
Created attachment 72695 [details] [review] Patch to enable indic printing in ascii mails As I found from my initial investigation that saving drafts converts them in html mode & then printing is perfect. Hence, I'm attaching a solution which is based on this approach. Thanks, Mayank
Downstream bug - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202751
Looks fine to commit.
Thanks Srinivasa :)
for the sake of better documentation, i'd love to see a gtk doc entry like the one for e_msg_composer_get_message - anyway, just nitpicking... :-)
Hi Andre :) Thats just a helper function, so i dont think a gtk style doc is reqd :)
hmm... right. /me needs a coffee. makuchaku, poke me again if you don't have commit permissions :-)
e_msg_composer_get_message_print() needs to be declared in e-msg-composer.h since it's called from another module, otherwise it's going to fail my -Werror-implicit-function-declaration test. I'll take care of it.
Mayank, e_msg_composer_get_message_print() takes a boolean argument named "save_html_object_data" but doesn't do anything with it. But it calls: msg = build_message (composer, TRUE); where the second argument of build_message() is also a boolean argument named "save_html_object_data". Should it be passing the flag along? If not, can we drop the unnecessary boolean argument?
Hi Matthew, I agree that what you are saying is true. I might have kept "save_html_object_data" just to keep the new call consistant with the old one. If removing this bool variable has no effect, please go ahead. Thanks for pointing out this mistake, i'll be more carefull the next time. :) Mayank
Created attachment 74425 [details] [review] Revised patch Here's a slightly revised version of Mayank's original patch. It declares the new function in e-msg-composer.h, and changes - msg = build_message (composer, TRUE); + msg = build_message (composer, save_html_object_data); This approach is less disruptive than pruning dead "save_html_object_data" parameters caused by the hardcoded TRUE argument. Mayank, are you okay with this version?
Yup, looks fine :) If it passes the testing, i have absolutely no problem :) Matthew, thanks for clearing my mess.
Marking the first patch as obsolete. Mailer hackers: Can you pl. review the updated patch ?
Stop reviewing. This patch does fix the reported problem but it also makes Evolution send all email with both text/plain and text/html content, whether HTML is selected in the composer or not. We need to find a different solution for this one.
Update patch status per comment #14.
Created attachment 76171 [details] [review] Revised patch This patch seems to work better. It avoids the previously mentioned side-effects. Mayank came up with the solution and I just tidied up the logic a bit.
Thanks Matthew :)
Created attachment 78697 [details] [review] Revised patch The first hunk in the previous patch was causing things like meeting requests to be sent as text/plain. Here's a revised patch with the naughty bits snipped.
*** Bug 349877 has been marked as a duplicate of this bug. ***
Comment #20 From Matthew Barnes on 2006-11-07 I tidied up the logic a bit and verified that the reported problem as well as the previous side-effects are fixed. I'll submit a new patch upstream. Fixed in evolution-2.9.2-2.fc7. Comment #22 From Matthew Barnes on 2006-11-13 Bug #208803 (for RHEL-5) was verified and resolved with the same patch, so I'm resolving this bug as well. Feel free to re-open it if you still encounter the problem or any of the documented side-effects from previous attempts. so matthew, can we get this in for 2.11?
Matthew, can you get this in for 2.11.5?
The patch was shipped with RHEL5 and passed QA testing. Committed to trunk (revision 34099).