Why are there no automatic line breaks when text from Gnome's Text Editor 45.1 is copied and no 'Returns' or line feeds when a text file is opened in Windows?

Ask Fedora
, , ,
1

I wrote several paragraphs of text in Gnome’s Text Editor 45.1. Most of the paragraphs were so long that automatic line breaks were done. Everything was displayed correctly. However, when I copied the whole text and pasted it into my webmailer (website of my email provider in the browser) and sent the email, there were no line breaks any more in the sent email but endlessly long lines, which were only displayed when I scrolled to the right with the scroll bar.

When a text file with several paragraphs, that was displayed correctly and saved with EDIT: Gnome’s Text Editor, was opened in Windows, there were no ‘Returns’ or line feeds any more.

What are the reasons for the two problems?

2

This condition (problem) has existed from the very beginning between windows and linux. The differences seem not destined to change…

Text files created within withdows have lines that end with [cr][lf] characters.
text files created within linux have lines that end with [lf] only.

[cr][lf] == carriage return + line feed
[lf] == line feed

If you were to look at the source code of the html displayed by your browser you may see the differences. In times past html code written using a windows text editor then displayed on a browser did not display correctly because of the differences in the characters used at the end of each line.

Any hex editor used to display the content of the text file will also show the differences in the hidden characters used at the ends of lines in files created by the two very different OSes.

NOTE:
You seem to also be confusing automatic line wrapping on your screen or in the editor with actual characters used to terminate a line. Those are very different things. Automatic line wrapping depends upon the app displaying the text, the width of the window used, and how it all is configured.
Fixed line width is done with a [lf] character (for windows the [cr][lf] pair) at the end of each line (and may be inserted automatically by the editor in certain apps). But then once again may become automatically wrapped (or not) depending upon how long the line is and how it is viewed.

3

@computersavvy With the second problem, the text file was saved with Gnome’s Text Editor (see my EDIT):

I wasn’t using a MS Windows text editor. Gnome’s Text Editor was used.

I don’t quite understand your post.

Thank you for your general information regarding the differences of text files created with Windows and Linux in the end characters of the lines.

So, is the reason for the second problem the different end characters of the lines in Linux and in Windows text files?

What is the reason for the first problem (where text from Gnome’s Text Editor was copied)?

4

As I stated, the editor you used did automatic line wraps so there are no line feeds at the displayed end of each line and everything looks normal.

This means the tool used to display it afterward only ends the line at the paragraph end where you manually inserted a line break at the end.

You would see the same thing by copy & paste of the same text into a post here using the preformatted text tags – which would give an extremely long line requiring scrolling to the line end to read it – or not using the preformatted text tags – which would allow automatic line wrap.

This paragraph is preformatted text containing several manual line feeds for formatting

    Arb is free software: you can redistribute it and/or modify it under
    the terms of the GNU Lesser General Public License (LGPL) as published
    by the Free Software Foundation; either version 2.1 of the License, or
    (at your option) any later version.  See <http://www.gnu.org/licenses/>.

The same paragraph without the manual line feeds but using preformatted tags

    Arb is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL) as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.  See <http://www.gnu.org/licenses/>.

And the same paragraph without preformatted tags and no line feeds. I think this will show the differences in display formatting by your browser (which usually does automatic line wrap) vs preformatted display.

“Arb is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL) as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. See <Licenses - GNU Project - Free Software Foundation>.”

5

@computersavvy Is it possible that the problem, regarding no line breaks any more in the sent email but endlessly long lines, which were only displayed when I scrolled to the right with the scroll bar, doesn’t exist when Libre Office Writer is used (instead of Gnome’s Text Editor) or do I just not remember correctly?

6

Different text editor – different operation.
Seems quite possible to me that what is saved may also be different.

After all the gnome text editor is basic while libreoffice is a full fledged document composer that includes a lot of formatting options.

Look at what is available under ‘styles’, ‘format’, and ‘insert’ to see the many different settings, some of which may automatically add the line feeds as well as spacing, font control, etc., and almost all of which will include hidden characters into the text.

1 Like
7

@computersavvy I don’t know any more, whether the file was saved or whether the text was copied within an unsaved document.

Does this play a role for the problem?

8

Don’t know.
You might test to find out.

9

Just as an additional bit of info.
When saving docs from libreoffice the filename extension does affect the format of the output.
For example the default extension is .odt and means it is saved in open document text format. Using .txt saves it in a (mostly) clean text format. Other options are available including the microsoft xls or xlsx formats.