[Issue] Carriage Return converted to Line Feed when opening CSV file

[Monster]

Hi.
OpenOffice Calc converts Carriage Return to Line Feed when opening a csv-file.
Is there a way to change this behaviour?

[Hagar Delest]

Hi and welcome to the forum!

Can you upload a sample file showing that (see How to attach a document here)?
I don't see that with LibreOffice and I'm not sure CSV makes the difference between carriage return and line feed. Thus, can't see how AOO/LO could make the difference.

[Monster]

I have attached the original file and two screenshots:
Original file:

Screenshot-orig.jpg (23.36 KiB) Viewed 833 times

File after opening and saving:

Screenshot-after-open-and-save.jpg (22.92 KiB) Viewed 833 times

[MrProgrammer]

OpenOffice Calc converts Carriage Return to Line Feed when opening a csv-file.

Issue 82952 - CSV import is wrong on CR (0x13) value

[Villeroy]

Specify the text delimiter as " (double-quote) and you get the ID and three lines of text in cell B2.

[MrProgrammer]

Specify the text delimiter as " (double-quote) and you get the ID and three lines of text in cell B2.

Yes, however the Carriage Return characters U+000D in the CSV file were imported as Linefeed characters U+000A in B2, as shown in the image below. This is what the OpenOffice issue describes.

Data in CSV files is often in strange configurations, depending on what conventions the creator used. In this case we have a CRLF sequence written as three(!) characters: CarriageReturn Backslash n. It's hardly surprising that Calc cannot support every weird convention that might exist. Since the Linefeed was created as \n it's odd that Carriage Return isn't \r. \r\n would import/export properly, though it wouldn't display as multi-line in a cell. If the goal is to have multi-line cell value, Calc has done the import properly since only Linefeed does that. =1&CHAR(10)&2 displays as two lines; =1&CHAR(13)&2 as one.

202306011029.png (80.37 KiB) Viewed 743 times

[Hagar Delest]

At least the import follows the intent of the writer it seems. Since for the ID 1, the string was designed to be on 3 lines.
Thus in this case, it is not really a bug. It is just an operation to be done on that kind of content.