After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765092 - When replying a mail, the cutting of the lines doesn't keep the text in a flow any more
When replying a mail, the cutting of the lines doesn't keep the text in a flo...
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Composer
3.20.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Tomas Popela
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2016-04-15 10:18 UTC by Andres Gomez
Modified: 2020-04-27 15:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andres Gomez 2016-04-15 10:18:59 UTC
With the new composer, in plain text mode, when you reply an email the tex may be now cut in a very bad way, not having the proper flow.

For example, for an email with Normal format of the type.

<mail>
Lorem Ipsum is simply dummy text of the printing and typesetting
industry. Lorem Ipsum has been the industry's standard dummy text
ever since the 1500s, when an unknown printer took a galley of
type and scrambled it to make a type specimen book. It has
survived not only five centuries, but also the leap into
electronic typesetting, remaining essentially unchanged. It was
popularised in the 1960s with the release of Letraset sheets
containing Lorem Ipsum passages, and more recently with desktop
publishing software like Aldus PageMaker including versions of
Lorem Ipsum.
</mail>


Before the new composer, the Reply would appear like:

<mail>
> Lorem Ipsum is simply dummy text of the printing and
> typesetting industry. Lorem Ipsum has been the industry's
> standard dummy text ever since the 1500s, when an unknown
> printer took a galley of type and scrambled it to make a type
> specimen book. It has survived not only five centuries, but
> also the leap into electronic typesetting, remaining
> essentially unchanged. It was popularised in the 1960s with the
> release of Letraset sheets containing Lorem Ipsum passages, and
> more recently with desktop publishing software like Aldus
> PageMaker including versions of Lorem Ipsum.
</mail>

With the new composer, it appears like:

<mail>
> Lorem Ipsum is simply dummy text of the printing and
> typesetting
> industry. Lorem Ipsum has been the industry's standard dummy
> text
> ever since the 1500s, when an unknown printer took a galley of
> type and scrambled it to make a type specimen book. It has
> survived not only five centuries, but also the leap into
> electronic typesetting, remaining essentially unchanged. It
> was
> popularised in the 1960s with the release of Letraset sheets
> containing Lorem Ipsum passages, and more recently with
> desktop
> publishing software like Aldus PageMaker including versions of
> Lorem Ipsum.
</mail>


Reproduced with Evo 3.18.5.1 in Debian Testing
Comment 1 Tomas Popela 2016-04-15 10:35:32 UTC

*** This bug has been marked as a duplicate of bug 756883 ***
Comment 2 Andres Gomez 2016-06-21 08:32:59 UTC
This is not a DUPLICATED of bug 756883. That bug, only adds an option to automatically wrap text (use Normal format) or not wrap text (use Preformatted format).

Obviously, with "Preformatted" we won't have these cuts in the lines ... but the lines won't be wrapped.

With "Normal" we have the lines wrapped but cut in a very bad way which is a *regression* from the previous composer, as shown in comment #0.

Hence, reopening.
Comment 3 Andres Gomez 2016-06-21 08:35:53 UTC
FTR, I can still reproduce this in Debian Testing 3.20.3-1
Comment 4 Milan Crha 2020-04-27 15:14:51 UTC
A lot of things had been changed for 3.37.2 development version, where the composer code had been rewritten to use JavaScriptCore API. I'm closing this in favor of that change. Please retest with that (will be part of the 3.38 stable release).

I'd need a test message (it depends what the message contains), to test this properly. Tomas did mark this correctly as a duplicate of the bug about the options, from my point of view, because once a text/plain message contains line breaks it cannot be determined whether they are soft or hard line breaks (in contrast to HTML).