Bug 109119 - Formated number and date calc cell formats don't respect automatic cell wrap
Summary: Formated number and date calc cell formats don't respect automatic cell wrap
Status: CLOSED DUPLICATE of bug 40685
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Merge-Split
  Show dependency treegraph
 
Reported: 2017-07-14 12:37 UTC by Jan-Marek Glogowski
Modified: 2017-07-25 08:11 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example document with first cell not wrapped (20.93 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-14 12:37 UTC, Jan-Marek Glogowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2017-07-14 12:37:31 UTC
Created attachment 134627 [details]
Example document with first cell not wrapped

Calc can set the alignment option for formated cells to "Wrap cells automatically" (Alignment _> properties).

I was told one of the first fixes for LO Calc was to prevent breaking of date and number values, ignoring the format and the "wrap cells" setting, but I couldn't find any reasoning.

I also know AOO - at some point - prevented to break the actual numbers / dates values, which I could also not understand, but this probably improves visibility. There is also https://bz.apache.org/ooo/show_bug.cgi?id=111387, but this just prevents breaking of numbers, if they use the autodecimal feature.

But in the case of a number formated as a string with spaces, this doesn't make much of a sense and is actually counter-intuitive, especially since the "Wrap cells automatically" defaults to off.

The attached document has user defined format code of "nächste Besprechung: "DD.MM.YY. In AOO 4.1.0 the cell is line wrapped after the column resulting in a two line cell. LO just displays ###. BTW: "Wrap cells automatically" is selected.

Now there is a crazy workaround, probably due to some inconsistency: set the alignment of the cell to justification, but this doesn't help with existing documents.

I was told this is "expected" behaviour for number and date formated cells.

BTW: unicode has actually NO-BREAK SPACE (http://www.fileformat.info/info/unicode/char/00a0/index.htm), which is not regarded as a whitespace, and so prevents a line break, but I guess it's too late to use this for all the old formattings.

I probably missed the documentation, but at least there was no information in the online doc for the "Wrap cells automatically" feature.
Comment 1 Jan-Marek Glogowski 2017-07-14 12:46:03 UTC
This might be a duplicate of bug 40685, but the comments mixes space and breaking the number.
Comment 2 Eike Rathke 2017-07-14 14:28:28 UTC
Consider user defined formats like
[$$-409]_ _-_ 0.00;[$$-409] - 0.00
You do not want to line break the display anywhere, even worse if the row height is not tall enough to display excess lines.

We could replace all unquoted spaces with NBSP to prevent breaks at those positions, but that would have to be done for all number (not date) format codes including those read from file formats. That still does not solve the problem that row heights may not be sufficient to display subsequent lines for date format codes that do use normal spaces.

A far better approach IMHO is to automatically widen the column after input (only!) if it is too narrow and was not yet set to a fixed width by the user. Which also Gnumeric and Excel do.

Both also do not wrap numeric and date display strings if wrap is enabled, so we'd display significantly different content if we implemented wrapping here.

*** This bug has been marked as a duplicate of bug 40685 ***