GNOME Bugzilla – Bug 237830
re-editing Draft looses format (whitespace)
Last modified: 2015-03-12 14:05:12 UTC
When re-editing a Draft in text/plain mode (not HTML) leeding whitespaces get lost. Steps to reproduce the problem: - create a new Mail (non HTML) - write lines with a leading space - save Draft - edit that Draft (double click) Actual Results: - the leading space is gone Expected Results: - give me my space back ;-) How often does this happen? - always Additional Information: - the whitespace is saved in the draft (see below) but omitted when re-editing - double whitespaces in the text are saved when re-editing --- the Draft in view/source --- Subject: bug: Draft From: <xxxx> To: <xxxx> Content-Type: multipart/alternative; boundary="=-Yw/3s6eYi/hZyEzfmhlq" X-Evolution-Account: xxxx X-Evolution-Format: text/plain Date: 11 Feb 2003 00:32:33 +0100 Message-Id: <1044919953.11297.24.camel@monkey> Mime-Version: 1.0 --=-Yw/3s6eYi/hZyEzfmhlq Content-Type: text/plain Content-Transfer-Encoding: 7bit first line one space before (2 before space) last line --=-Yw/3s6eYi/hZyEzfmhlq Content-Type: text/html; charset=utf-8 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/1.1.8"> </HEAD> <BODY> first line<BR> <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="0"> one space before (2 before space)<BR> last line<BR> <!--+GtkHTML:<DATA class="ClueFlow" key="signature_name" value="name:huffman"><!--+GtkHTML:<DATA class="ClueFlow" key="signature" value="0"><BR> </BODY> </HTML> --=-Yw/3s6eYi/hZyEzfmhlq-- ---
what version of gtkhtml do you have?
% rpm -qa | grep gtkhtml gtkhtml1.1-1.1.8-1.ximian.1 libgtkhtml2_0-2.0.1-1mdk nautilus-gtkhtml-0.3.2-4mdk libgtkhtml1.1-3-1.1.8-1.ximian.1 libgtkhtml20-1.0.4-6.ximian.1
Additional info: I just saw, that the message is displayed in the Draft folder with variable width font -- although it is text/plain format.
I tried this with evolution 2.2.2 and gtkhtml2-3.6.2 This is working fine for me. If you don't mind can pls verify this with latest version of Evolution and gtkhtml moving to need info
This one is still valid. Just tested this with Evolution 2.4.1, GtkHTML 3.8.2. In fact, 2 spaces are preserved correctly. One leading space is not. Additional info: This is not limited to drafts. Open two Composers. Write a line with one leading space in the Composer. Copy that line and paste it into the other Composer. Note the space being gone.
*** Bug 242408 has been marked as a duplicate of this bug. ***
Please see duplicate bug 242408 for another instance, that loses whitespace formatting in Drafts. In this case, tab chars are lost and substituted by a single space. In general, do not drop or change any whitespace chars, when saving Drafts.
Created attachment 61884 [details] [review] patch
Continous Whitespaces in drafts are stored as N-1 and 1 &sp; In case of 1 leading whitespace, there's only one &sp; Hence the &sp; is removed.
*** Bug 353524 has been marked as a duplicate of this bug. ***
Note comment 7. When saving text/plain mails as Draft, whitespace handling is poor. This does *not* apply to spaces only. In general, any number of whitespaces (spaces, tabs, etc.) must be preserved as entered by the user. Note that this does *not* apply to the first char only. *Any* occurence of multiple spaces or tab chars must be preserved. Adjusting Summary to reflect the whitespace case only. Patch (attachment 61884 [details] [review]) needs work. This misses way too much cases. Usability issue, adding keyword.
Because <a href="http://bugzilla.gnome.org/show_bug.cgi?id=353524" title="tabs are lost when saving draft in text format">bug 353524</a> is marked as a duplication of this bug, I will continue the discussion here.
As for bug 353524, I think the cause is that tabs are ignored by html engine if the mail is TEXT format(the draft will be saved as multipart/alternative). So we have 3 solutions: 1.Do not save the mail in TEXT format as multipart/alternative, just save it as plain text mail. In this case we have to make a little modification of evolution. 2.When we read the draft, read the correct part from multipart mail. For TEXT mail we read TEXT part, for HTML mail we read HTML part. In this case we have to make modification of evolution too and it's a little more complicated. 3.Make html engine expand tabs to nbsp. In this case we have to make modification of gtkhtml, and it's complicated too.
I have 2 patches for the 1st solution and the 2nd solution and posted them in the report of bug 353524. But they are for evolution not gtkhtml, so I am not sure if I can post them here. If not I will re-open the bug 353524.
Wang, if this happens to actually be an issue with Evo rather than GtkHTML, we can simply change the Product of this bug. Also, good observation that this can be fixed easily within Evo and thanks for the patches! :) Moving them here, so they will be more visible. NOTE: Description and discussion of the patches and another possible solution in bug 353524 comment 4.
Created attachment 74896 [details] [review] Proposed solution 1, see bug 353524 comment 5, by Wang Xin patch to make the composer do not save html section for TEXT format draft
Created attachment 74898 [details] [review] Proposed solution 2, see bug 353524 comment 6, by Wang Xin the patch to make evolution read the right section from drafts
# copying bug 353524 comment 4, by Wang Xin I think the cause is that tabs are ignored by html engine if the mail is TEXT format(the draft will be saved as multipart/alternative). So we have 3 solutions: 1.Do not save the mail in TEXT format as multipart/alternative, just save it as plain text mail. In this case we have to make a little modification of evolution. 2.When we read the draft, read the correct part from multipart mail. For TEXT mail we read TEXT part, for HTML mail we read HTML part. In this case we have to make modification of evolution too and it's a little more complicated. 3.Make html engine expand tabs to nbsp. In this case we have to make modification of gtkhtml, and it's complicated too.
Actually, I agree with Wang. Also, messing around with whitespaces and forcing non-breaking ones isn't a good solution for HTML anyway. Solution 1 or 2 sounds way promising. Therefore, moving over to Evolution / Mailer.
Comment on attachment 74896 [details] [review] Proposed solution 1, see bug 353524 comment 5, by Wang Xin I'm for the solution 2, read the proper section from saved draft, thus I'm rejecting this patch.
Comment on attachment 74898 [details] [review] Proposed solution 2, see bug 353524 comment 6, by Wang Xin I applied this patch to current master (replaced non-existing e_msg_composer_get_send_html with FALSE in the first file) and it doesn't work. Could you update your patch to actual master, please? From my point of view, dealing with em-format.c here is not the best thing, most of the things should be able to be done in composer only.
This might be finally fixed for 3.16.0 with the webkit-based composer. Tomas, please verify and eventually close this bug report. Thanks.
I can confirm that this is fixed in WebKit based composer.