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.
This might be a duplicate of bug 40685, but the comments mixes space and breaking the number.
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 ***