Description: Setting an indent level for text in a cell reverts to 0pt after saving, closing and re-opening file. Steps to Reproduce: 1. In Calc select a cell or complete column. 2. Select Format>Cells... then change Text Alignment>Horizontal-Left>Indent-2pt. 3. Save and close sheet, then re-open. Indent reverts to 0pt. Actual Results: Cell indent reverts to 0pt. Expected Results: Cell indent is saved. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: SpreadsheetDocument [Information guessed from browser] OS: Mac OS X (All) OS is 64bit: no
What file format to save?
XLSX
Repro in Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded and Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4debb7e8cc12563f46d1aaa58afdcb831f21cc83 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: CL Described behaviour was reproduced when used 2 pt indent. However, when used 5 pt as left indent, it changed to 15 pt after re-opening.
Already seen with 6.3 and 3.3.0. Did not find any earlier reports.
Does it save when you set a bigger indent value? This should be the same issue as discussed in bug 130104. When save as xlsx, the indent value should be convert to an interger value (e.g.1, 2, 3, this is how OOXML defines it, these numbers mean the width of white char multiplied by this int value). Thus a smaller indent in pt such as 2pt may be rounded to zero when converting to an interger value. See https://opengrok.libreoffice.org/xref/core/sc/source/filter/excel/xestyle.cxx?r=b8cfea65#1461 where it first calculates a nTmpIndent of type tools::Long nTmpIndent = (nTmpIndent + 100) / 200; and then limit_cast it to an int: mnIndent = limit_cast< sal_uInt8 >( nTmpIndent, 0, 15 );
and based on my experiment there is no ideal solution. The minimum value is interger 1, but if you open the saved xlsx it will appear wider than 2pt...
I guess we can close as dupe. 1-4 turn into 0, then 5 turns into 15 pt. *** This bug has been marked as a duplicate of bug 130104 ***
I have submitted a patch in bug Bug 130104. However, please consider the following cases: 1. Currently in Calc, if you click the "Indent" toolbar icon once, it increase the indent for a step of 10pt. 2. In the cell format dialog, you can still set another indent value other than those of multiple of 10pt. 3. In Excel, the indent value of "1" equals the width of 3 space chars (using the default font) in Excel. However, in my patch, I intentionally converts the Excel "1" indent to the 10pt "step", thus Excel indent "2" would be 20pt etc. Also, upon resave as xlsx, those multiples of 10pt is converted back to the excel "1", "2", "3" etc. 4. An indent value smaller than the "10pt" step is treated as Excel 0 indent. I think this is the best choice, otherwise it is very difficult to make a compromise on these two sides. If you set the indent using the toolbar icon, then you only get multiples of 10pt; I should assume that those who are setting the indent using the cell format dialog knows what he is doing. 5. I tried to implement the XLSX import to treat the Excel Indent 1 to be 3 space char width, but this way would be totally a mess both in the re-save process and also when you modify the indent using the toolbar icon. Base on the above analysis, I should consider this bug as WONTFIX rather than a duplicate of bug 130104. What do you think?
This is NOTABUG. The correct save is handled elsewhere, and there the question is, how to calculate the integer number of three-space intents correctly; however, there will always be a minimal indent representable in XLS(X) - limited by the format.
Changing status