Description of problem: when you wrote some other langauge (other than English) in message Body, printout is empty, showing Nothing Version-Release number of selected component (if applicable): evolution-2.7.91-4 How reproducible: Everytime, when you put multi-lang text in body Steps to Reproduce: 1. Open Evolution ->Mail - New Mail 2. in body put some text from http://ja.wikipedia.org/ (copy and paste in Subject/To Area) 3. Print the mail Actual results: Subject/To areas are printed properly, but Body is not printed Expected results: Mail body should print Additional info: tested with CJK/Indic languages
Even the print preview does not works fine. It shows exactly the same output as the printout. Another anomaly I noticed in rawhide, that it was taking more than a minute to generate the print preview. Aman, can you please confirm this behaviour? Thanks, Mayank
This is what i've found from my initial investigation build_message from e-msg-composer.c is called to build the mail message which can be printed. For headers (to/bcc/from/subject), this build_message directly picks ups text from the gtk widgets using... return gtk_entry_get_text ((GtkEntry *) hdrs->priv->subject.entry); However, it tries to find a charset & encoding combination based ont the contents of text body through best_charset and best_encoding functions, which goes haywire!
*** Bug 204451 has been marked as a duplicate of this bug. ***
Files/functions of interest... $evo/plugins/print-message/print-message.c : org_gnome_print_message --> data->msg = e_msg_composer_get_message (composer, 1); $evo/composer/e-msg-composer.c : e_msg_composer_get_message (EMsgComposer *composer, gboolean save_html_object_data) --> return build_message (composer, save_html_object_data); $evo/composer/e-msg-composer.c : build_message (EMsgComposer *composer, gboolean save_html_object_data) --> if (p->mime_body) {
Created attachment 136148 [details] Patch to enable indic printing in ascii mails Printing from HTML was getting done, So I formulated my solution on the same approach. Patch up for review :)
Matthew, over to you... I've added the gnome bugzilla ID, lets see how the review goes :) Thanks, Mayank
Got the patch approved upstream :) Thanks Srag!
[from gnome bz] Comment #8 from Matthew Barnes (points: 13) 2006-09-25 16:36 UTC [reply] 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. Comment #9 from Matthew Barnes (points: 13) 2006-09-25 16:50 UTC [reply] 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? [/from gnome bz] 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. Please upload the new patch too. :) Mayank
Mayank, I think I'm still seeing the problem even with your patch applied, but I'm not sure I'm testing this correctly. I also seem to be missing some fonts. Here's some screenshots of what I'm getting.
Created attachment 137611 [details] Composer screenshot
Created attachment 137612 [details] Print Preview screenshot
Hi Matthew, #10 is because of fonts & #11 *might* be because of fonts as well. Okay, follow this test case... 1) yum install fonts-hindi 2) Copy & paste some hindi text from http://hi.wikipedia.com 3) Test print/print-preview functionality. Thanks, Mayank
Re: Comment #5 Mayank, This bug is on multi-lang text printing, is the patch applicable for this problem?
Yup, I yet again tested the patch with hindi+japanese text. Print & print-preview both work.
Mayank, please have a look at my revised patch in the upstream bug. Your solution seems to be working for me now.
From Matthew Barnes (mbarnes) The patch does fix the reported problem, but it also causes Evolution to send all email with both text/plain and text/html content, regardless of whether HTML has been selected in the composer.
Created attachment 139833 [details] wrong headers as created by this patch as compared to right headers
Created attachment 140449 [details] Modified patch
Created attachment 140540 [details] Updated patch, fixes memory leak of temp_composer and func declaration in header file.
Thanks, Mayank. 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.
Thanks Matthew :)
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.