1262742 - Line-break Wrong in Quoted-printable

Status: RESOLVED DUPLICATE of bug 1225904

(Thunderbird :: Untriaged, defect)

Description

[Jonathan Joseph Chiarella]

Attachment: long-line-test-source.txt

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160304114936

Steps to reproduce:

1. Settings: format=flowed off (causes problems with PGP signing. Though I did not experience issues, format=flowed does not fix lines starting with >, nor does it fix nested quotes. If it is not set to DelSp=Yes format=flowed it is useless for writing systems that do not use spaces, e.g., Han script Chinese or kana script Japanese). Word wrap disabled (set to "0")

2. Type a long line of ASCII characters, at least 1000. Or, type a string of Han script characters (for simplicity's sake, assume no Western numerals and only 3-byte characters and punctuation), at least 334.

3. Use PGP/MIME and sign the document to force quoted-printable content-transfer-encoding. (Though you may choose to use another method of triggering qp since this bug affects all quoted-printable output).


Actual results:

1. The cutoff for a single line appears to be 999 bytes (999 ASCII characters or 333 CJK characters, for example)

2. After the 999th byte (byte #998 if counting from zero), a hard line break (CR LF) is added in the source.

3. There is a hard line break displayed after the 999th byte (bye #998 if counting from zero) even though the line is longer and should not be broken up. This causes the text to no longer flow properly.


Expected results:

1. The cutoff for a single line should be at 998 bytes (byte #997 if counting from zero).

2. a) Thunderbird should break the line after the 998th byte (byte #997 if counting from zero), but tell the module that does quoted-printable to add a soft-line break after the 998th byte (=).

OR

2. b) Quoted-printable should be applied BEFORE Thunderbird inserts the break. Each quoted-printable line will be 76 characters (76 bytes) or fewer and not trigger any hard line breaks.

Comment 1

[Jonathan Joseph Chiarella]

Please note that this bug is not directly related to #878616 <https://bugzilla.mozilla.org/show_bug.cgi?id=878616>. That bug concerns format=flowed or else the wording is misleading. I keep format=flowed deactivated since it never works properly and space-stuffing and whether to quote as ">" or "> " were never standardized and there is no accepted way of removing stuffed spaces. Additionally, few implement the only practical version DelSp=Yes and few MUA even bother with writing out DelSp=No. Format=flowed is useless for long URLs or many non-Latin scripts.

Gmail's webmail client smartly sees long lines and changes the text to quoted-printable or Base64, whichever is more practical, and handles the line breaks how I would hope (a la "2. b)" that I listed above. For someone who writes in Asian scripts QP is a nightmare. However, with modern computers, the 1:3 size ratio is tolerable. I am limiting my bug filing to how QP is implemented. As far as I know, Thunderbird does not use Base64 in text bodies.

Thank you all for your hard work. Of course, this bug filing relates to MIME, not to inline PGP encoding, which ASCII armors everything anyway.

If possible, I would like to see Thunderbird switch to QP (or even Base64) for regular text emails that are NOT MIME and have long lines (e.g., 999+ bytes of data). Thunderbird could scan for any lines longer than that and trigger QP (or Base64) for the message body *and* do it intelligently. (I.e., fix the hard line breaks at 999 bytes.)

Comment 2

[Jonathan Joseph Chiarella]

Also, as an example. Here is an excerpt from a letter by Qiu Jin. 399 characters in one paragraph. (No hard line breaks.)

这还不说，到了择亲的时光，只凭着两个不要脸媒人的话，只要男家有钱有势，不问身家清白，男人的性情好坏、学问高低，就不知不觉应了。到了过门的时候，用一顶红红绿绿的花轿，坐在里面，连气也不能出。到了那边，要是遇着男人虽不怎么样，却还安分，这就算前生有福今生受了。遇着不好的，总不是说“前生作了孽”，就是说“运气不好”。要是说一二句抱怨的话，或是劝了男人几句，反了腔，就打骂俱下，别人听见还要说不贤慧，不晓得妇道呢！诸位听听，这不是有冤没处诉么？还有一桩不公的事：男子死了，女子就要带三年孝，不许二嫁。女子死了，男人只带几根蓝辫线，有嫌难看的，连带也不带，人死还没三天，就出去偷鸡摸狗，七还未尽，新娘子早已进门了。上天生人，男女原没有分别。试问天下没有女人，就生出这些人来么？为甚么这样不公道呢？那些男子，天天说“心是公的，待人是要和平的”，又为甚么把女子当作非洲的黑奴一样看待，不公不平，直到这步田地呢？

I have played around with the advanced settings and tried every permutation of the 5 advanced options for line wrapping set to true or false or 0 vs. a positive number for "mailnews.wraplength".

mailnews.wraplength only applies to the number of characters, not the number of bytes. So I can't force wrapping at 998 in any circumstance.

Also, mailnews.wraplength has no effect whatsoever on an unbroken line of ASCII numbers that is 999 or more characters/bytes in length.

Comment 3

[Jorg K (CEST = GMT+2)]

All this is fixed and will be released in TB 45 in a week or so. See bug 1225904, bug 1225864 and bug 653342.