Bug 160983

How to?, CSV is imported as unformatted text, what it is.

Not sure why you are asking how to, when I import some CVS files with wide text columns or text columns that include new line characters, Calc first imports the CSV files then spends time "adjusting the row heights" according to the status message at the bottom of the window. The some rows of the CVS files end up being marked as 39.37" high, and scrolling in Calc is brain damaged such that you get large jumps and can't review them at all. Since there is no inherent height information in the CSV file, Calc is the one actor performing this behavior. It seems readily analogous to that being done when reading an ODF or XLS file.

But these adjustments are not by the format, only length and new lines, something that LO knows when importing.
But there is no format on the csv text, like bold e.g.
The only thing is to apply the style you need to the data, by modifying one that already exist or creating a new one. Even you can modify default style.

Maybe better create a template just for that, first create a new file with that template then use
 Menu/Sheet
 - Insert sheet
 - Insert sheet from file
 - External links
for the two first you can set up it as link, so an update is possible., without recreated the import.

This has been also requested here: https://www.reddit.com/r/libreoffice/comments/nj3oll/can_i_have_preset_for_row_height_and_column_width/

I couldn't reproduce the issue with ridiculous row heights when importing a CSV. Do you have an example file?

Created attachment 194285 [details]
sample CSV with a lot of text in one cell

Not reproduce with this file and:

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 101b08fe1ec77ffe8c1a9b2b8f9f20884269a1ed
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

I'll have to sanitize and pare one down to reasonable dimensions, they contain proprietary data.

Created attachment 194309 [details]
Example CSV that exhibits the behavior when imported

CSV import options:
   From row: 1
   Separated by: comma
   String delimiter: double quote mark
   Format quoted field as text: yes

> scalc --version
LibreOffice 24.2.3.2 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba

Created attachment 194312 [details]
Sampled file after import

No issue for me with:
Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

Created attachment 194313 [details]
Screenshot import dialog.

I see the "calculating" message and the high-height cells (e.g. at row 54) when importing the sample file with only comma as a delimiter.

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

I can see how it can be frustrating for users wanting to edit simple formats like CSV/TSV, expecting LO to handle it as simply as possible.

Ideally, you'd expect a simple on/off setting in the import dialog, along the lines of "Adapt row height to fit contents"? Or something different?

Justin and Balazs, you recently worked on RecalcOptimalRowHeightMode, what do you think? 

Copying the UX/Design team in for opinion.

(In reply to Stéphane Guillou (stragu) from comment #10)
> I see the "calculating" message and the high-height cells (e.g. at row 54)
> when importing the sample file with only comma as a delimiter.
Me don't, although it takes some milliseconds to process. Line 1197 aka log data point #2097 is more extreme, and I struggle with the use case of putting a novel into a single cell. The example encloses a long string with quotation marks and RecalcOptimalRowHeightMode does its job as expected.

> I can see how it can be frustrating for users wanting to edit simple formats
> like CSV/TSV, expecting LO to handle it as simply as possible.
Sure, if CSV is kept simple. But the example is some kind of log file with an (X)ML format.

(In reply to Stéphane Guillou (stragu) from comment #10)
(e.g. at row 54)

Cell B54 includes line-breaking characters. They should not be modified by the import process.

Either, Rows nor Columns get any modification (they would not adapt at all, leaving both axis with default values only, no matter the contents), or they get some kind of adapting to contents.

Some users won't like the first alternative, whereas others won't like the second possibility (and both groups will complain). I am not sure that simply changing the behavior would be considered as an improvement. I would agree to let users modify the respective sizes manually after importing, but other users won’t like that, especially newbies.

Providing choice (about one behavior or the other) for users might be seen as improvement, but that means adding some checkbox somewhere.

(In reply to Heiko Tietze from comment #11)

> Me don't, although it takes some milliseconds to process.

Same here, but maybe the attachment is just a simplified case(?).

You definitely want to have row height automatically calculated for a CSV import, since CSV cannot possibly specify a height for any row. Otherwise any multiline data (like row 54) would be "hidden" - looking like single line data (like row 53).

CSV is always a transitional format. You load it once, then format it according to your liking and then export it into an appropriate format.

Other than avoiding a performance penalty, I can't imagine any reason not to want to have the row height be calculated at load time. The proper response to being irritated about the speed is to optimize row height calculation.

[That said, I did say in my XLSX commit "I can't think of a reason why this shouldn't apply to all formats". As a code pointer, see https://gerrit.libreoffice.org/c/core/+/164721 ]

(In reply to ady from comment #12) 
> Some users won't like the first alternative, whereas others won't like the
> second possibility (and both groups will complain). I am not sure that
> simply changing the behavior would be considered as an improvement.
OP is not asking for a change in the default behaviour.

RecalcOptimalRowHeightMode is an advanced configuration option that affects whether rows that do not mandate a specific height should have that height calculated at import time.
  -yes (default - no change in behaviour)
  -no (useful for ODS which I believe knows the last-used-height at import)
  -ask

P.S. I just checked ScDocShell::ConvertTo SC_TEXT_CSV_FILTER_NAME and it does NOT set bSetRowHeights to true. So doing what OP asks would not be as trivial as I thought it might be.

Still a WONTFIX from me. Only useful for formats that already know an appropriate height.